Gateway apparatus and methods for wireless iot (internet of things) services

ABSTRACT

Gateway apparatus and methods for providing data services (including IoT data services) which leverage existing managed network (e.g., cable network) infrastructure. The disclosed methods and apparatus enable, among other things, delivery of IoT data services in a unified manner via a common portal or IoT gateway (IoTG) which may be both remotely accessed by a user, and remotely controlled/configured by the host network operator (e.g., MSO). In one variant, the premises devices include RF-enabled receivers (enhanced consumer premises equipment, or CPEe) configured to receive (and transmit) OFDM waveforms via a coaxial cable drop to the premises, and interface with the aforementioned IoTG to enable provision of both 5G high-speed data services and lower bandwidth IoT services to the premises, all via a single coaxial cable drop in the exemplary embodiment.

PRIORITY AND RELATED APPLICATIONS

This application is a divisional of and claims priority to co-owned andco-pending U.S. patent application Ser. No. 16/384,805 filed on Apr. 15,2019, issuing as U.S. Pat. No. 11,190,861 on Nov. 30, 2021, and entitled“GATEWAY APPARATUS AND METHODS FOR WIRELESS IOT (INTERNET OF THINGS)SERVICES,” which claims the benefit of priority to U.S. ProvisionalPatent Application No. 62/658,465 filed Apr. 16, 2018 and entitled“APPARATUS AND METHODS FOR INTEGRATED HIGH-CAPACITY DATA AND WIRELESSNETWORK SERVICES”, which is incorporated herein by reference in itsentirety.

This application is also related to co-owned and co-pending U.S. patentapplication Ser. No. 16/216,835 entitled “APPARATUS AND METHODS FORINTEGRATED HIGH-CAPACITY DATA AND WIRELESS NETWORK SERVICES” filed Dec.11, 2018, Ser. No. 16/261,234 entitled “APPARATUS AND METHODS FORENABLING MOBILITY OF A USER DEVICE IN AN ENHANCED WIRELESS NETWORK”filed Jan. 29, 2019, Ser. No. 16/384,706 entitled “APPARATUS AND METHODSFOR COORDINATED DELIVERY OF MULTIPLE DATA CHANNELS OVER PHYSICAL MEDIUM”filed Apr. 15, 2019, Ser. No. 16/384,561 entitled “APPARATUS AND METHODSFOR INTEGRATED HIGH-CAPACITY DATA AND WIRELESS IoT (INTERNET OF THINGS)SERVICES” filed Apr. 15, 2019, and Ser. No. 16/384,701 entitled“APPARATUS AND METHODS FOR ENHANCING QUALITY OF EXPERIENCE FOROVER-THE-TOP DATA SERVICES OVER HIGH-CAPACITY WIRELESS NETWORKS” filedApr. 15, 2019, each of the foregoing incorporated herein by reference inits entirety.

COPYRIGHT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND 1. Technological Field

The present disclosure relates generally to the field of data networksand wireless devices, and specifically in one exemplary aspect to anarchitecture which integrates or unifies provision of high-speed dataservices including “Internet of Things” or IoT services, in a variety ofdifferent locations and use cases.

2. Description of Related Technology

Data communication services are now ubiquitous throughout user premises(e.g., home, office, and even vehicles). Such data communicationservices may be provided via a managed or unmanaged network. Forinstance, a typical home has services provided by one or more networkservice providers via a managed network such as a cable or satellitenetwork. These services may include content delivery (e.g., lineartelevision, on-demand content, personal or cloud DVR, “start over”,etc.), as well as so-called “over the top” third party content.Similarly, Internet and telephony access is also typically provided, andmay be bundled with the aforementioned content delivery functions intosubscription packages, which are increasingly becoming more user- orpremises-specific in their construction and content. Such services arealso increasingly attempting to adopt the paradigm of “anywhere”,anytime,” so that users (subscribers) can access the desired services(e.g., watch a movie) via a number of different receiving and renderingplatforms, such as in different rooms of their house, on their mobiledevice while traveling, etc.

Managed Cable Networks

Network operators deliver data services (e.g., broadband) and videoproducts to customers using a variety of different devices, therebyenabling their users or subscribers to access data/content in a numberof different contexts, both fixed (e.g., at their residence) and mobile(such as while traveling or away from home). FIGS. 1 and 2 are afunctional block diagrams illustrating a typical prior art managed(e.g., cable) content delivery network architecture used to provide suchdata services to its users and subscribers.

Data/content delivery may be specific to the network operator, such aswhere video content is ingested by the network operator or its proxy,and delivered to the network users or subscribers as a product orservice of the network operator. For instance, a cable multiple systemsoperator (MSO) may ingest content from multiple different sources (e.g.,national networks, content aggregators, etc.), process the ingestedcontent, and deliver it to the MSO subscribers via e.g., a hybrid fibercoax (HFC) cable/fiber network, such as to the subscriber's set-top boxor DOC SIS cable modem. Such ingested content is transcoded to thenecessary format as required (e.g., MPEG-2 or MPEG-4/AVC), framed andplaced in the appropriate media container format (“packaged”), andtransmitted via e.g., statistical multiplex into a multi-programtransport stream (MPTS) on 6 MHz radio frequency (RF) channels forreceipt by the subscribers RF tuner, demultiplexed and decoded, andrendered on the user's rendering device (e.g., digital TV) according tothe prescribed coding format.

Within the cable plant, VOD and so-called switched digital video (SDV)may also be used to provide content, and utilize a single-programtransport stream (SPTS) delivery modality. In U. S. cable systems forexample, downstream RF channels used for transmission of televisionprograms are 6 MHz wide, and occupy a 6 MHz spectral slot between 54 MHzand 860 MHz. Deployments of VOD services have to share this spectrumwith already established analog and digital cable television servicessuch as those described above. Within a given cable plant, all homesthat are electrically connected to the same cable feed running through aneighborhood will receive the same downstream signal. For the purpose ofmanaging e.g., VOD services, these homes are grouped into logical groupstypically called Service Groups. Homes belonging to the same ServiceGroup receive their VOD service on the same set of RF channels.

VOD service is typically offered over a given number (e.g., 4) of RFchannels from the available spectrum in cable. Thus, a VOD Service Groupconsists of homes receiving VOD signals over the same 4 RF channels.

In most cable networks, programs are transmitted using MPEG (e.g.,MPEG-2) audio/video compression. Since cable signals are transmittedusing Quadrature Amplitude Modulation (QAM) scheme, available payloadbitrate for typical modulation rates (QAM-256) used on HFC systems isroughly 38 Mbps. For example, in many VOD deployments, a typical rate of3.75 Mbps is used to send one video program at resolution and qualityequivalent to NTSC broadcast signals. In digital television terminology,this is called Standard Definition (SD) television resolution.Therefore, use of MPEG-2 and QAM modulation enables carriage of 10 SDsessions on one RF channel (10×3.75=37.5 Mbps<38 Mbps). Since a typicalService Group consists of 4 RF channels, 40 simultaneous SD VOD sessionscan be accommodated within a Service Group.

Entertainment-quality transmission of HD (High Definition) signalsrequires about four times as much bandwidth as SD. For an exemplaryMPEG-2 Main Profile—High Level (MP@HL) video compression, each HDprogram requires around 15 Mbps bitrate.

Wireless

A multitude of wireless networking technologies, also known as RadioAccess Technologies (“RATs”), provide the underlying means of connectionfor radio-based communication networks to user devices. Such RATs oftenutilize licensed radio frequency spectrum (i.e., that allocated by theFCC per the Table of Frequency Allocations as codified at Section 2.106of the Commission's Rules). Currently only frequency bands between 9 kHzand 275 GHz have been allocated (i.e., designated for use by one or moreterrestrial or space radio communication services or the radio astronomyservice under specified conditions). For example, a typical cellularservice provider might utilize spectrum for so-called “3G” (thirdgeneration) and “4G” (fourth generation) wireless communications asshown in Table 1 below:

TABLE 1 Technology Bands 3G  850 MHz Cellular, Band 5 (GSM/GPRS/EDGE).1900 MHz PCS, Band 2 (GSM/GPRS/EDGE).  850 MHz Cellular, Band 5(UMTS/HSPA+ up to 21 Mbit/s). 1900 MHz PCS, Band 2 (UMTS/HSPA+ up to 21Mbit/s). 4G  700 MHz Lower B/C, Band 12/17 (LTE).  850 MHz Cellular,Band 5 (LTE). 1700/2100 MHz AWS, Band 4 (LTE). 1900 MHz PCS, Band 2(LTE). 2300 MHz WCS, Band 30 (LTE).

Alternatively, unlicensed spectrum may be utilized, such as that withinthe so-called ISM-bands. The ISM bands are defined by the ITU RadioRegulations (Article 5) in footnotes 5.138, 5.150, and 5.280 of theRadio Regulations. In the United States, uses of the ISM bands aregoverned by Part 18 of the Federal Communications Commission (FCC)rules, while Part 15 contains the rules for unlicensed communicationdevices, even those that share ISM frequencies. Table 2 below showstypical ISM frequency allocations:

TABLE 2 Frequency Center range Type frequency Availability Licensedusers  6.765 MHz- A   6.78 MHz Subject Fixed service &  6.795 MHz  tolocal mobile service acceptance 13.553 MHz- B  13.56 MHz Worldwide Fixed& mobile 13.567 MHz  services except aeronautical mobile (R) service26.957 MHz- B  27.12 MHz Worldwide Fixed & mobile 27.283 MHz  serviceexcept aeronautical mobile service, CB radio  40.66 MHz- B  40.68 MHzWorldwide Fixed, mobile   40.7 MHz  services & earth exploration-satellite service 433.05 MHz- A 433.92 MHz only in amateur service &434.79 MHz  Region 1, radiolocation service, subject additional applythe to local provisions of acceptance footnote 5.280   902 MHz- B   915MHz Region 2 Fixed, mobile   928 MHz  only except aeronautical (withsome mobile & exceptions) radiolocation service; in Region 2 additionalamateur service   2.4 GHz- B  2.45 GHz Worldwide Fixed, mobile,   2.5GHz  radiolocation, amateur & amateur- satellite service  5.725 GHz- B  5.8 GHz Worldwide Fixed-satellite,  5.875 GHz  radiolocation, mobile,amateur & amateur- satellite service    24 GHz- B 24.125 GHz WorldwideAmateur, amateur-  24.25 GHz  satellite, radiolocation & earthexploration-satellite service (active)    61 GHz- A  61.25 GHz SubjectFixed, inter-satellite,  61.5 GHz  to local mobile & acceptanceradiolocation service   122 GHz- A  122.5 GHz Subject Earth exploration-  123 GHz  to local satellite (passive), acceptance fixed,inter-satellite, mobile, space research (passive) & amateur service  244 GHz- A   245 GHz Subject Radiolocation,   246 GHz  to local radioastronomy, acceptance amateur & amateur-satellite service

ISM bands are also been shared with (non-ISM) license-freecommunications applications such as wireless sensor networks in the 915MHz and 2.450 GHz bands, as well as wireless LANs (e.g., Wi-Fi) andcordless phones in the 915 MHz, 2.450 GHz, and 5.800 GHz bands.

Additionally, the 5 GHz band has been allocated for use by, e.g., WLANequipment, as shown in Table 3:

TABLE 3 Dynamic Freq. Selection Band Name Frequency Band Required (DFS)UNII-1 5.15 to 5.25 GHz No UNII-2 5.25 to 5.35 GHz Yes UNII-2 Extended 5.47 to 5.725 GHz Yes UNII-3 5.725 to 5.825 GHz No

User client devices (e.g., smartphone, tablet, phablet, laptop,smartwatch, or other wireless-enabled devices, mobile or otherwise)generally support multiple RATs that enable the devices to connect toone another, or to networks (e.g., the Internet, intranets, orextranets), often including RATs associated with both licensed andunlicensed spectrum.

In particular, wireless access to other networks by client devices ismade possible by wireless technologies that utilize networked hardware,such as a wireless access point (“WAP” or “AP”), small cells,femtocells, or cellular towers, serviced by a backend or backhaulportion of service provider network (e.g., a cable network). A user maygenerally access the network at a node or “hotspot,” a physical locationat which the user may obtain access by connecting to modems, routers,APs, etc. that are within wireless range.

One such technology that enables a user to engage in wirelesscommunication (e.g., via services provided through the cable networkoperator) is Wi-Fi® (IEEE Std. 802.11), which has become a ubiquitouslyaccepted standard for wireless networking in consumer electronics. Wi-Fiallows client devices to gain convenient high-speed access to networks(e.g., wireless local area networks (WLANs)) via one or more accesspoints.

Commercially, Wi-Fi is able to provide services to a group of userswithin a venue or premises such as within a trusted home or businessenvironment, or outside, e.g., cafes, hotels, business centers,restaurants, and other public areas. A typical Wi-Fi network setup mayinclude the user's client device in wireless communication with an AP(and/or a modem connected to the AP) that are in communication with thebackend, where the client device must be within a certain range thatallows the client device to detect the signal from the AP and conductcommunication with the AP.

Another wireless technology in widespread use is Long-Term Evolutionstandard (also colloquially referred to as “LTE,” “4G,” “LTE Advanced,”among others). An LTE network is powered by an Evolved Packet Core(“EPC”), an Internet Protocol (IP)-based network architecture andeNodeB—Evolved NodeB or E-UTRAN node which part of the Radio AccessNetwork (RAN), capable of providing high-speed wireless datacommunication services to many wireless-enabled devices of users with awide coverage area.

Currently, most consumer devices include multi-RAT capability; e.g.; thecapability to access multiple different RATs, whether simultaneously, orin a “fail over” manner (such as via a wireless connection managerprocess running on the device). For example, a smartphone may be enabledfor LTE data access, but when unavailable, utilize one or more Wi-Fitechnologies (e.g., 802.11g/n/ac) for data communications.

The capabilities of different RATs (such as LTE and Wi-Fi) can be verydifferent, including regarding establishment of wireless service to agiven client device. For example, there is a disparity between thesignal strength threshold for initializing a connection via Wi-Fi vs.LTE (including those technologies configured to operate in unlicensedbands such as LTE-U and LTE-LAA). As a brief aside, LTE-U enables datacommunication via LTE in an unlicensed spectrum (e.g., 5 GHz) to provideadditional radio spectrum for data transmission (e.g., to compensate foroverflow traffic). LTE-LAA uses carrier aggregation to combine LTE inunlicensed spectrum (e.g., 5 GHz) with the licensed band. Typical levelsof signal strength required for LTE-U or LTE-LAA service areapproximately −80 to −84 dBm. In comparison, Wi-Fi can be detected by aclient device based on a signal strength of approximately −72 to −80dBm, i.e., a higher (i.e., less sensitive) detection threshold.

Increasing numbers of users (whether users of wireless interfaces of theaforementioned standards, or others) invariably lead to “crowding” ofthe spectrum, including interference. Interference may also exist fromnon-user sources such as solar radiation, electrical equipment, militaryuses, etc. In effect, a given amount of spectrum has physicallimitations on the amount of bandwidth it can provide, and as more usersare added in parallel, each user potentially experiences moreinterference and degradation of performance.

Moreover, technologies such as Wi-Fi have limited range (due in part tothe unlicensed spectral power mask imposed in those bands), and maysuffer from spatial propagation variations (especially inside structuressuch as buildings) and deployment density issues. Wi-Fi has become soubiquitous that, especially in high-density scenarios such ashospitality units (e.g., hotels), enterprises, crowded venues, and thelike, the contention issues may be unmanageable, even with a plethora ofWi-Fi APs installed to compensate. Yet further, there is generally nocoordination between such APs, each in effect contending for bandwidthon its backhaul with others.

Additionally, lack of integration with other services provided by e.g.,a managed network operator, typically exists with unlicensed technologysuch as Wi-Fi. Wi-Fi typically acts as a “data pipe” opaquely carried bythe network operator/service provider.

5G New Radio (NR) and NG-RAN (Next Generation Radio Area Network)—

NG-RAN or “NextGen RAN (Radio Area Network)” is part of the 3GPP “5G”next generation radio system. 3GPP is currently specifying Release 15NG-RAN, its components, and interactions among the involved nodesincluding so-called “gNBs” (next generation Node B's or eNBs). NG-RANwill provide very high-bandwidth, very low-latency (e.g., on the orderof 1 ms or less “round trip”) wireless communication and efficientlyutilize, depending on application, both licensed and unlicensed spectrumof the type described supra in a wide variety of deployment scenarios,including indoor “spot” use, urban “macro” (large cell) coverage, ruralcoverage, use in vehicles, and “smart” grids and structures. NG-RAN willalso integrate with 4G/4.5G systems and infrastructure, and moreover newLTE entities are used (e.g., an “evolved” LTE eNB or “eLTE eNB” whichsupports connectivity to both the EPC (Evolved Packet Core) and the NR“NGC” (Next Generation Core). As such, both “standalone” (SA) and“non-standalone” (NSA) configurations are described. As discussed ingreater detail below, in the SA scenario, the 5G NR or the evolved LTEradio cells and the core network are operated alone. Conversely, in NSAscenarios, combination of e-UTRAN and NG-RAN entities are utilized.

In some aspects, exemplary Release 15 NG-RAN leverages technology andfunctions of extant LTE/LTE-A technologies (colloquially referred to as4G or 4.5G), as bases for further functional development andcapabilities. For instance, in an LTE-based network, upon startup, aneNB (base station) establishes S1-AP connections towards the MME(mobility management entity) whose commands the eNB is expected toexecute. An eNB can be responsible for multiple cells (in other words,multiple Tracking Area Codes corresponding to E-UTRAN Cell GlobalIdentifiers). The procedure used by the eNB to establish theaforementioned S1-AP connection, together with the activation of cellsthat the eNB supports, is referred to as the S1 SETUP procedure; seeinter alia, 3GPP TS 36.413 V14.4. entitled “3rd Generation PartnershipProject; Technical Specification Group Radio Access Network; EvolvedUniversal Terrestrial Radio Access Network (E-UTRAN); S1 ApplicationProtocol (S1AP) (Release 14)” dated September 2017, which isincorporated herein by reference in its entirety.

As a brief aside, and referring to FIG. 3a (an SA configuration), the CU304 (also known as gNB-CU) is a logical node within the NR architecture300 that communicates with the NG Core 303, and includes gNB functionssuch as transfer of user data, session management, mobility control, RANsharing, and positioning; however, other functions are allocatedexclusively to the DU(s) 306 (also known as gNB-DUs) per various “split”options described subsequently herein in greater detail. The CU 304communicates user data and controls the operation of the DU(s) 306, viacorresponding front-haul (Fs) user plane and control plane interfaces308, 310.

Accordingly, to implement the Fs interfaces 308, 310, the (standardized)F1 interface is employed. It provides a mechanism for interconnecting agNB-CU 304 and a gNB-DU 306 of a gNB 302 within an NG-RAN, or forinterconnecting a gNB-CU and a gNB-DU of an en-gNB within an E-UTRAN.The F1 Application Protocol (F1AP) supports the functions of F1interface by signaling procedures defined in 3GPP TS 38.473. F1APconsists of so-called “elementary procedures” (EPs). An EP is a unit ofinteraction between gNB-CU and gNB-DU. These EPs are defined separatelyand are intended to be used to build up complete messaging sequences ina flexible manner. Generally, unless otherwise stated by therestrictions, the EPs may be invoked independently of each other asstandalone procedures, which can be active in parallel.

Within such an architecture 300, a gNB-DU 306 (or ngeNB-DU) is under thecontrol of a single gNB-CU 304. When a gNB-DU is initiated (includingpower-up), it executes the F1 SETUP procedure (which is generallymodeled after the above-referenced S1 SETUP procedures of LTE) to informthe controlling gNB-CU of, inter alia, any number of parameters such ase.g., the number of cells (together with the identity of each particularcell) in the F1 SETUP REQUEST message.

FIGS. 3b-3d illustrate some of the alternate prior art configurations of5G NR gNB architectures, including those involving eLTE eNB (evolved LTEeNBs that are capable of communication with an NGC or EPC) and variousconfigurations of user-plane and control-plane interfaces in theso-called “non-standalone” or NSA configurations (e.g., Options 3, 4 and7). See, inter alia, 3GPP TR 38.804 V14.0.0 (2017-03)—“3rd GenerationPartnership Project; Technical Specification Group Radio Access Network;Study on New Radio Access Technology; Radio Interface Protocol Aspects(Release 14),” incorporated herein by reference in its entirety, foradditional details on these and other possible 4G/5G configurations.

In FIG. 3b , a eUTRAN eNB 316 is communicative with the 5G gNB 302 foruser plane (UP) and control plane (CP) functions, and is communicativewith the NGC 303 for UP functions (i.e., the gNB is a master node inconjunction with a 5GC).

In FIG. 3c , a eUTRAN eNB 316 is communicative with the 5G gNB 302 foruser plane (UP) and control plane (CP) functions, and is communicativewith the NGC 303 for UP and CP functions (i.e., the eNB is a master nodein conjunction with a 5GC).

In FIG. 3d , a 5G gNB 302 is communicative with the eNB 316 for userplane (UP) and control plane (CP) functions, and is communicative withthe Evolved Packet Core (EPC) 333 for UP functions (i.e., the eNB is amaster node in conjunction with an EPC).

As of the date of this writing, 3GPP is delivering Release 15 toindustry in three distinct steps: (i) ‘early’ drop: containsNon-standalone 5G specifications (so called Option-3 family), ASN.1frozen in March 2018; (ii) ‘main’ drop: contains Standalone 5G (socalled Option-2), ASN.1 frozen in September 2018; and (iii) ‘late’ drop:contains additional migration architectures (so called Option-4,Option-7, and 5G-5G dual connectivity), ASN.1 to be frozen in June 2019.See http//www.3gpp.org/news-events/3gpp-news/2005-ran_r16_schedule.

IoT Devices

Also useful to the user is data relating to other “intelligent” devicesand services, such as e.g., those within the user's premises. Forexample, computerized devices within the user's premises other thanthose provided by, or associated with the services of the MSO or serviceprovider, may exist, including for instance personal electronics,appliances, security systems, and home automation systems. One emergingclass of such non-service provider devices are so called “IoT” or“Internet of Things” devices, aimed at providing enhanced datacommunication functionality between the IoT devices and third parties(e.g., a service provider), and between the IoT devices themselves.

Internet of Things (IoT) development has leveraged miniaturization,cloud solutions, faster processing speeds, reduced costs of components,and use of data analytics to benefit from real-time data collected frome.g., the user's premises. IoT is somewhat of an evolution ofMachine-to-Machine (M2M); while M2M typically utilizes directcommunication links, IoT expands to connectivity via IP networks andother infrastructure. M2M applications typically utilize singleapplications and most of the time are characterized by a “one device—oneapplication” paradigm. In contrast, IoT is constructed to support “onedevice to many applications” and conversely “many devices to few (orone) application” operations.

Various IoT use cases and applications have been identified. In one typeof application, very large numbers of connected objects residing, forexample, in buildings, agricultural fields, shipping vehicles, are usedand contact “the cloud” using low-cost devices with low energyconsumption, sufficient geographic coverage, and relatively highscalability. Conversely, more “critical” IoT applications such ashealthcare, traffic management, and industrial/utility controls, requirehigh availability and reliability as well as very low latency.

Enhanced Machine-Type Communication (eMTC) and Narrowband IoT (NB-IoT),are exemplary technologies expected to offer applicability to a widevariety of IoT use cases such as those described above. The3GPP-specified eMTC and NB-IoT, together with a variety of unlicensedlow power technologies, provide an array of wireless connectivityoptions that enable so-called Low Power Wide Area Networks (LPWANs).

The key improvement areas addressed by the 3GPP standards (i.e.,including Release 13) include device cost, battery life, coverage andsupport for massive numbers of IoT connections. Security is also anissue at all levels of the IoT “fabric.” Accordingly, enhancedMachine-Type-Communication (eMTC) and Narrowband IoT (NB-IoT)technologies each support state-of-the-art 3GPP security, includingauthentication, signaling protection, and data encryption.

Notably, as compared to say the broadband data traffic referenced above,the data traffic from most IoT applications will be relatively small andeasily absorbed into the bearer network(s).

In 3GPP Releases 14, 15 and beyond (including 5G referenced supra),standards aim at more fully integrating and enabling IoT applicationswith 5G's ultra-low latency, high reliability, high connectivity, andvery high bandwidth capabilities, including real-time control andautomation of dynamic processes in various fields such asvehicle-to-vehicle, vehicle-to-infrastructure, high-speed motion, andprocess control.

Unlicensed IoT devices can use any number of lower- and higher-layerprotocol stacks. Many are based on the IEEE Std. 802.15.4 WPAN MAC/PHY(including Zigbee and Thread), while others utilize BLE (Bluetooth LowEnergy, also referred to colloquially as Bluetooth Smart). Thesetechnologies utilize unlicensed portions of the radio frequency spectrum(e.g., ISM bands in the U.S.) for communication, and may attempt toavoid interference or conflict with other ISM-band technologies such asWi-Fi (IEEE Std. 802.11).

Currently, the following non-exhaustive list of exemplary technologiesare available or under development for unlicensed IoT applications:

Zigbee—ZigBee 3.0 is based on IEEE Std. 802.15.4, and operates at anominal frequency of 2.4 GHz as well as 868 and 915 MHz (ISM), supportsdata rates on the order of 250 kbps, and has a range on the order of10-100 meters. Zigbee radios use direct-sequence spread spectrum (DSSS)spectral access/coding, and binary phase-shift keying (BPSK) is used inthe 868 and 915 MHz bands, and offset quadrature phase-shift keying(OQPSK) that transmits two bits per symbol is used for the 2.4 GHz band.

Z-Wave—Z-Wave technology is specified by the Z-Wave Alliance StandardZAD12837 and ITU-T G.9959 (for PHY and MAC layers). It operates in theU.S. at a nominal frequency of 900 MHz (ISM), as shown in Table 4 below:

TABLE 4 Center frequency Data rate Channel Width Region G.9959 MHzG.9959 kHz United States f_(US1) 916.00 R3 400 of America f_(US2) 908.40R2 300 R1 300 R1-Type 1 of supported data rate-9.6 kbps R2-Type 2 ofsupported data rate-40 kbps R3-Type 3 of supported data rate-100 kbps

Z-Wave has a range on the order of 30 meters, and supports full meshnetworks without the need for a coordinator node (as in 802.15.4). It isscalable, enabling control of up to 232 devices. Z-Wave uses a simplerprotocol than some others, which can ostensibly enable faster andsimpler development. Z-Wave also supports AES128 encryption and IPv6.

6LowPAN—6LowPAN (IPv6 Low-power wireless Personal Area Network) is anIP-based network protocol technology (rather than an IoT applicationprotocol technology such as Bluetooth or ZigBee), as set forth in RFC6282. 6LowPAN defines encapsulation and header compression mechanisms,and is not tied to any particular PHY configuration. It can also be usedalong with multiple communications platforms, including Ethernet, Wi-Fi,802.15.4 and sub-1 GHz ISM. The IPv6 (Internet Protocol version 6) stackenables embedded objects or devices to have their own unique IP address,and connect to the Internet. IPv6 provides a basic transport mechanismto e.g., enable complex control systems, and to communicate with devicesvia a low-power wireless network.

For instance, 6LowPAN can send IPv6 packets over an IEEE 802.15.4-basednetwork which implements “open” IP standards such TCP, UDP, HTTP, COAP,MQTT, and websockets to enable end-to-end addressable nodes, allowing arouter to connect the network to IP. Moreover, mesh router devices canroute data destined for other devices, while hosts are able to sleep(and hence conserve power).

Thread—Thread is a royalty-free protocol based on various standardsincluding IEEE Std. 802.15.4 (as the air-interface protocol) and6LoWPAN. It is intended to offer an IP-based solution for IoTapplications, and is designed to interoperate with existing IEEE Std.802.15.4-compliant wireless silicon. Thread supports mesh networkingusing IEEE Std. 802.15.4 radio transceivers, and can handle numerousnodes, including use of authentication and encryption.

Bluetooth Smart/BLE—Bluetooth Smart or BLE is intended to provideconsiderably reduced power consumption and cost while maintaining asimilar communication range to that of conventional Bluetooth radios.Devices that employ Bluetooth Smart features incorporate the BluetoothCore Specification Version 4.0 (or higher—e.g., Version 4.2 announced inlate 2014) with a combined basic-data-rate and low-energy coreconfiguration for a RF transceiver, baseband and protocol stack. Version4.2, via its Internet Protocol Support Profile, allows Bluetooth Smartsensors to access the Internet directly via 6LoWPAN connectivity(discussed supra). This IP connectivity enables use of existing IPinfrastructure to manage Bluetooth Smart “edge” devices. In 2017, theBluetooth SIG released Mesh Profile and Mesh Model specifications, whichenable using Smart for many-to-many device communications. Moreover,many mobile operating systems including iOS, Android, Windows Phone,BlackBerry, and Linux, natively support Bluetooth Smart.

The Bluetooth 4.2 Core Specification specifies a frequency of 2.4 GHz(ISM band), supports data rates on the order of 1 Mbps, utilizes GFSK(Gaussian Frequency Shift Keying) modulation, and has a typical range onthe order of 50 to 150 meters. BLE uses frequency hopping (FHSS) over 37channels (0-36) for (bidirectional) communication, and over 3 channelsfor (unidirectional) advertising. The Bluetooth 4.0 link-layer MTU is 27bytes, while 4.2 used 251 bytes. Core specification 5.0 (adopted Dec. 6,2016) yet further extends and improves upon features of the v4.2specification.

A BLE device can operate in four (4) different device roles, each whichmay cause the devices to behave differently. Two of the roles areconnection-based; i.e., a peripheral device is an advertiser that isconnectable and can operate as a slave as part of a two-way(bidirectional) data connection, and a central device that monitors foradvertisers, and can initiate connections operating as a master forthose connections. Conversely, the other two device roles are used forunidirectional communications; i.e., a broadcaster (a non-connectableadvertiser which, for example, merely broadcasts data from a sensor ofthe IoT device, or an observer that monitors for advertisements, butcannot initiate connections (e.g., the receiver for the above-referencedbroadcaster). Peripheral devices that implement a GATT Server(storage/exchange architecture) can be branded as a “Bluetooth Smart”device.

Longer Range IoT—Extant technologies adapted for intermediate range WAN(e.g., somewhere between cellular and WLAN) IoT functionalityapplications include Sigfox, Neul, and LoRaWAN. These are typicallyemployed for much longer distances than the comparatively short-rangePAN solutions described above.

For example, LoRaWAN™ is a Low Power Wide Area Network (LPWAN)technology intended for wireless battery operated devices. LoRaWANostensibly provides secure bi-directional communication, mobility andlocalization services. A LoRaWAN network is typically laid out in astar-of-stars topology, with gateways acting as transparent bridges torelay messages between end-devices and a centralized network server. Thegateways are connected to the network server via standard IPconnections, while the end-devices use wireless communication to one (ormultiple) gateways. All end-point communication is generallybi-directional; however, the technology also supports multicast enablingsoftware upgrade OTA and other distribution messages to reduce the onair communication time.

Communication between the aforementioned end-devices and gateways isdistributed on different frequency channels and data rates, and used“chirped FM” spread spectrum modulation operating in the 915 MHz ISMband. The selection of the data rate is a trade-off betweencommunication range and message duration. Due to the spread spectrumnature of LoRaWAN technology, communications with different data ratesdo not interfere with each other via creation of “virtual” channels.LoRaWAN data rates range from 0.3 kbps to 50 kbps. The LoRaWAN networkserver is configured to manage the data rate and RF output for eachend-device individually by means of an adaptive data rate (ADR) scheme,so as to, inter alia, optimize battery life/power consumption. LoRaWANsecurity is based on that under IEEE 802.15.4 standards, including AES128 bit encryption.

Device addresses (DevAddr) in LoRaWAN are structured as a 32-bitidentifier and are unique within the network, and are also present ineach data frame. DevAddr's are shared between end-devices, networkservers, and applications servers.

Various end-device classes have different behavior depending on thechoice of optimization; i.e., Battery Powered (Class A); Low Latency(Class B); and No Latency (Class C).

Generally speaking, two (2) classes or types of IoT installations withina premises can be envisioned to currently exist: (i) “transparent”installations, wherein the installed IoT end-devices are visible tonetwork devices, whether within or external to the premises; and (ii)“proxy managed” installations, wherein the installed IoT end-devices aremanaged by a proxy device such as a hub or gateway, and may be invisibleto network devices outside the proxy device. Some premises may alsofreely intermix these two types of installations, such as where some IoTdevices are behind a proxy and utilize a proprietary protocol of acommon manufacturer, while others are added “ad hoc” without regard tothe proxy or proprietary protocol (and which do not inter-communicatetherewith), as now described with respect to FIG. 4.

Referring to FIG. 4, in the first type of installation (“transparent”),individual IoT end-devices 402 within a premises 400 may be networkedaccording to various types of topologies (e.g., master-slave,peer-to-peer (P2P), coordinator-simple node, star, cluster, mesh, tree,or other), and may maintain their own status on the network via e.g.,assignment of an externally accessible IP address. This makes suchdevices 402 externally accessible and addressable for, inter alia,remote network entities 406 via any interposed networks such as theInternet 401 and the service provider distribution network 401. Forinstance, a web server 406 operated by a manufacturer of an IoT-enabledrefrigerator may be able to, assuming suitable permissions, communicatedirectly with the IoT device over the Internet 411 and interposed ISPmodem 405 (e.g., DOCSIS cable modem, DSP modem, etc.), a router 407, andlocal wireless access node 409 (e.g., an IEEE Std. 802.15.4 coordinatoror Bluetooth LE master) via its assigned IP address (e.g., an IPv4 orIPv6 address), such as to obtain data logged by the IoT refrigerator(e.g., internal/external temperature profile over time, door openings asa function of time, loss-of-power events, etc.), and/or “push” firmwareor other updates to the device such as to implement new or enhancedfunctions. The assigned IP address may be globally unique (i.e., suchthat it is unique across the Internet 411 external to the premises), oralternatively locally unique (e.g., unique within its local topology,but not necessarily globally unique). The latter can be translated (viae.g., NAT or network address translation functions) into the former suchas by a router 410 or other premises “edge” device configured to performNAT.

In the second type of installation (“proxy managed”), a hub 412 or otherintermediary device is interposed between the IoT end-device(s) 404 andthe service provider distribution network 401 external to the premises(including the modem 405 and router 407). The hub 412 may include, asshown, its own internal wireless access interface, whereby the “managed”IoT devices 404 communicate with the hub 412 wirelessly so as tocommunicate data. The protocols used between the hub 412 and the managedIoT devices 404 may be proprietary (e.g., at the higher layers of theprotocol stack, or even including proprietary PHY and lower layerprotocols), and may even employ security measures such as encryption ofdata, password protection, etc. so as to maintain the managed IoTdevices 404 and the hub itself less susceptible to surreptitiouscommunications, MITM attacks, etc.

The web server 406 may communicate with the IoT proxy (hub) 412, such asto “pull” data from, or “push” data to, the IoT end-devices 404. Forinstance, in one model, the hub periodically polls or receives data fromthe IoT devices 404, and then reports this aggregated data to the webserver 106 via a push/pull mechanism. For instance, the hub 412 may havean outward-facing API (application programming interface) whereby theweb server 406 or other process can implement the API function (e.g., adata “GET”). However, such API functionality (and hub access in general)is typically highly restricted, primarily for security and privacyreasons. Given that the hub 412 can “talk” to the managed IoT devices404, surreptitious access to the hub (and hence IoT devices 404) couldresult in a host of undesirable consequences, including third partiesreprogramming the IoT device 404, obtaining private use or other datafrom the devices 404 (e.g., how many times a user uses theirrefrigerator), accessing indigenous features of the device 404 (e.g.,turning on the camera function of a user's smart TV so as to be able tosee inside the user's premises), corrupting or accessing a user'sprivate data (including changing passwords for devices, so as to lockout the user akin to ransomware), and so forth.

Notwithstanding, one of the most powerful aspects of the “Internet ofThings” from an architectural perspective is in fact ubiquitousconnectivity; the ability for example of the aforementioned refrigeratorto interface with local or remote entities to enhance its performance,save the owner money on electric bills, diagnose/troubleshoot itself,and any other of numerous possible use cases, all militate in favor ofhigh levels of connectivity. Such is also true of adapting productsand/or services to particular user traits or habits; for instance,targeted service or advertising provision can be effectively based onuser-specific habits or traits (e.g., a person who frequently uses theirmicrowave oven may lean toward microwave-able food items, and maybenefit from advertising relating thereto).

Hence, there is a tension between providing pervasive connectivity andinformation-sharing, and the obvious security and privacy concerns asdescribed above.

As with personal computer technology when in its infancy, IoT technologyis still rapidly evolving, and mechanisms for standardization,simplicity and ease of operation (“user experience”), and otherdesirable attributes are not yet perfected or widely adopted. Forexample, one manufacturer's IoT-enabled device (e.g., refrigerator)might utilize one communication protocol, have its own device-specificor proprietary software stack (including user interface functions andmenus), and its own peculiarities regarding operation, as compared toanother device (e.g., a “smart” microwave oven) of another manufacturer.Regardless of whether the “transparent” or “proxy managed” architecturesreferenced above are used for a particular IoT-enabled device, there isalso setup and configuration required to enable data communication,including with other devices within the premises. Also, no unifiedinterface or ability to control is provided, due in large part to theheterogeneity of the various devices and their communication protocols,functions, and data connectivity needs.

Better Solutions Needed

Even with the great advances in wireless data rate, robustness andcoverage afforded by extant 4/4.5G (e.g. LTE/LTE-A) and WLAN (and otherunlicensed) systems, and corresponding IoT solutions outlined above,significant disabilities still exist, including with regard to providingpremises IoT services.

IoT devices of the type previously described are also contemplated to bewidely served under 5G NR paradigms (both NSA and SA). As such,mechanisms by which service to these IoT devices (such at an MSOsubscriber's premises) can be readily provided and integrated with othere.g., higher bandwidths services such as 5G NR UP (user plane) data, areneeded. Such integration may also obviate or overcome many of thedifficulties noted above with regard to IoT implementations under thecurrent state of the art; i.e., security concerns, reliability ofchannel quality, ubiquity of services, ready self-configuration orconfiguration of IoT functions and devices by service provider entitieswithout significant user involvement, and unified or easily accessiblecontrol of multiple heterogeneous IoT devices and services by a userwithin their premises.

Accordingly, improved apparatus and methods are needed to, inter alia,enable optimized delivery of ultra-high data rate services (both wiredand wireless) as well as lower bandwidth IoT services, and whichleverage extant network infrastructure (such as a single MSO cable“drop” to a given premises).

SUMMARY

The present disclosure addresses the foregoing needs by providing, interalia, apparatus and methods for providing optimized delivery of IoTservices and control of IoT devices within the served premises, whichleverage extant network infrastructure.

In one aspect of the disclosure, an IoT gateway apparatus is disclosed.In one embodiment, the gateway apparatus is served by a 5G-capableenhanced CPE (CPEe) which provides connectivity to an MSO HFCinfrastructure. The gateway includes a high-bandwidth data interfacewith the CPEe (and hence the MSO infrastructure and beyond), as well asa number of heterogeneous IoT wireless interfaces suitable for directcommunication with IoT devices within the served premises (e.g., thoseusing 802.15.4, BLE, LoRA, etc. communication protocols and serving avariety of different functions).

In another aspect, computerized apparatus configured to use of one ormore air interfaces within a premises for provision of IoT (Internet ofThings) data services is disclosed. In one embodiment, the computerizedapparatus includes: an RF (Radio Frequency) interface device configuredto at least receive RF signals from a radio frequency distributionnetwork; processor apparatus in data communication with the RF interfacedevice; a plurality of radio apparatus in data communication with theprocessor apparatus; and storage apparatus in data communication withthe processor apparatus and comprising at least one computer program,the at least one computer program comprising a plurality ofinstructions.

In one variant, the plurality of instructions are configured to, whenexecuted by the processor apparatus, cause the computerized apparatusto: process the received RF signals to extract data for respective onesof a plurality of IoT devices in data communication with thecomputerized apparatus via the plurality of radio apparatus; and utilizethe respective radio apparatus to transmit the extracted data to therespective ones of the IoT devices via respective radio frequency (RF)bands, each of the RF bands associated with a respective short-rangecommunications protocol.

In a further embodiment, the computerized apparatus includes: a datainterface, the data interface configured to communicate data with an RFinterface device of a network; processor apparatus in data communicationwith the data interface; a plurality of radio apparatus in datacommunication with the processor apparatus; and storage apparatus indata communication with the processor apparatus and comprising at leastone computer program, the at least one computer program comprising aplurality of instructions. In one variant, the instructions areconfigured to, when executed by the processor apparatus, cause thecomputerized apparatus to: utilize the plurality of radio apparatus toscan respective ones of radio frequency (RF) bands, each of the RF bandsassociated with a respective short-range communications protocol, thescans each configured to detect energy associated with a first RFtransmitter; based at least on the detection of energy within therespective RF band, cause synchronization with a signal emitted from thecorresponding RF transmitter using the respective short-rangecommunications protocol; and based at least on said synchronization withthe signal, cause utilization of a designated RF channel of the network.

In a further aspect, a method of utilizing a hybrid fiber coaxial (HFC)radio frequency (RF) network for distribution of radio frequency signalsencoding IoT (Internet of Things) data is disclosed. In one embodiment,the method includes: utilizing a first portion of an RF operatingspectrum of the hybrid fiber coaxial (HFC) radio frequency network toprovide communications compliant with a first wireless technology; andutilizing a second portion of the RF operating spectrum to provide theIoT data via communications compliant with a second wireless technology.The utilizing a second portion of the RF operating spectrum to providethe IoT data via communications compliant with the second wirelesstechnology includes utilizing a computerized gateway apparatus having aplurality of heterogeneous air interfaces for distribution of respectiveportions of the IoT data to respective IoT devices within a premisesserved by the computerized gateway.

In another aspect, methods and apparatus for distributing an IoT channelin an RF distribution network are disclosed. In one embodiment, a narrowbandwidth channel is employed within this system architecture that iscompatible with 3GPP IoT standards (i.e. eMTC, NB-IoT), and this channelis used for IoT transmissions to standard IoT end devices over a coaxialdistribution network. The coax RF distribution network serves as, interalia, a distributed antenna system for the IoT channel, and the CPEequipment transmits and receives the IoT RF signals on the desired RFfrequency channel. In one such variant, the IoT end devices are theconnection endpoints, with the CPEe acting in effect as a pass-throughdevice only.

In a further aspect, methods and apparatus for controlling different IoTtechnology devices using a gateway apparatus are disclosed. In oneembodiment, the gateway apparatus includes a 5G NR capable gatewayhaving multiple wireless IoT interfaces, and the disclosed architecturehas a unified application layer that operate irrespective of thedifferent access technologies; this application software can be accessedby e.g., a user device with a comparable or counterpart application.

In another aspect, a computerized premises device implementing one ormore of the foregoing aspects is disclosed and described. In oneembodiment, the device comprises a CPE having 5G NR capability, and isbackhauled via an extant coaxial cable drop. In one variant, the devicealso includes a plurality of IoT wireless interfaces, and provision forconnection with an externally mounted antenna for use in communicatingwith one or more of the external access nodes. In one implementation,the CPE is a CPEe that includes selective filtering apparatus forfiltering to isolate prescribed frequency bands transmitted over thecoaxial infrastructure and received by the CPEe. In anotherimplementation, frequency upconversion/downconversion apparatus is alsoused to upconvert/downconvert received RF band signals to a desiredcarrier frequency consistent with the aforementioned selectivefiltration.

In another aspect, a mobile computerized device capable of IoT enddevice control via an IoTG is disclosed and described. In oneembodiment, the device comprises a personal or laptop computer. Inanother embodiment, the device comprises a mobile device (e.g., tabletor smartphone). In another embodiment, the device comprises acomputerized “smart” television or rendering device.

In another aspect, an integrated circuit (IC) device implementing one ormore of the foregoing aspects is disclosed and described. In oneembodiment, the IC device is embodied as a SoC (system on Chip) device.In another embodiment, an ASIC (application specific IC) is used as thebasis of the device. In yet another embodiment, a chip set (i.e.,multiple ICs used in coordinated fashion) is disclosed. In yet anotherembodiment, the device comprises a multi-logic block FPGA device.

In another aspect, a computer readable storage apparatus implementingone or more of the foregoing aspects is disclosed and described. In oneembodiment, the computer readable apparatus comprises a program memory,or an EEPROM. In another embodiment, the apparatus includes a solidstate drive (SSD) or other mass storage device. In another embodiment,the apparatus comprises a USB or other “flash drive” or other suchportable removable storage device. In yet another embodiment, theapparatus comprises a “cloud” (network) based storage device which isremote from yet accessible via a computerized user or client electronicdevice. In yet another embodiment, the apparatus comprises a “fog”(network) based storage device which is distributed across multiplenodes of varying proximity and accessible via a computerized user orclient electronic device.

In yet another aspect, a software architecture is disclosed. In oneembodiment, the architecture includes a unified application layerprocess configured to run on an IoT capable CPE (e.g., CPEe or IoTG),and which is accessible via e.g., MSO or external application servers,and mobile devices of the user.

In a further aspect, a method of utilizing a dedicated existing RFchannel for other purposes is disclosed. In one embodiment, the channelcomprises a 3GPP NSA LTE anchor channel, and the method includesallocating a portion of this channel's bandwidth to a secondary orembedded channel, such as for CPEe control and/or IoT data functions. Inone variant, the allocation is dynamic, such that the channel can beused different functions/purposes as a function of time, such as afunction of TDD slot timing, LTE channel load, and/or other parameters.

In yet a further aspect, a method of utilizing a dedicated existing RFchannel for other purposes is disclosed. In one embodiment, the channelcomprises a 3GPP NSA LTE anchor channel, and the method includesallocating a portion of this channel's bandwidth to a secondary orembedded channel on a time-divided or TDD allocation basis, such as forsupporting IoT data functions for a variety of different IoT devices ina premises. In one variant, the allocation is dynamic, such that thechannel can be used different functions/purposes as a function of time,such as a function of TDD slot timing, LTE channel load, and/or otherparameters.

These and other aspects shall become apparent when considered in lightof the disclosure provided herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 are a functional block diagrams illustrating a typicalprior art managed (e.g., cable) content delivery network architecture.

FIG. 3a is a functional block diagram of a prior art gNB architectureincluding CU and multiple DUs.

FIG. 3b is a functional block diagram of a prior art NSA gNB and eLTEeNB architecture including a 5G NR Core (NGC).

FIG. 3c is a functional block diagram of another prior art NSA gNB andeLTE eNB architecture including a 5G NR Core (NGC).

FIG. 3d is a functional block diagram of another prior art NSA gNB andeLTE eNB architecture including an Evolved Packet Core (EPC).

FIG. 4 is a functional block diagram of typical prior art IoTarchitectures for network connectivity.

FIG. 5 is a functional block diagram of an exemplary MSO networkarchitecture comprising various features described herein.

FIG. 5a is a functional block diagram of a first exemplary premisesnetwork architecture comprising the IoTG (IoT Gateway) described herein,useful with the MSO architecture 500 of FIG. 5.

FIG. 5b is a functional block diagram of a second exemplary premisesnetwork architecture comprising the IoTG (IoT Gateway) described hereincombined in a common form factor with the enhanced CPE (CPEe) and WLANrouter, useful with the MSO architecture 500 of FIG. 5.

FIG. 6a is a functional block diagram of one exemplary embodiment of agNB architecture including CUe and multiple DUes in standalone (SA)configuration, according to the present disclosure.

FIG. 6b is a functional block diagram of another exemplary embodiment ofa gNB architecture including multiple CUes and multiple correspondingDUes (SA), according to the present disclosure.

FIG. 6c is a functional block diagram of yet another exemplaryembodiment of a gNB architecture including multiple CUes logicallycross-connected to multiple different cores (SA), according to thepresent disclosure.

FIG. 6d is a functional block diagram of an NSA gNB and eLTE eNBarchitecture including a 5G NR Core (NGC) according to the presentdisclosure.

FIG. 6e is a functional block diagram of a gNB and LTE eNB architectureincluding an Evolved Packet Core (EPC) according to the presentdisclosure.

FIG. 6f is a functional block diagram of an NSA gNB and eLTE eNBarchitecture including an Evolved Packet Core (EPC) according to thepresent disclosure.

FIGS. 7a and 7b illustrate exemplary downstream (DS) and upstream (US)data throughputs or rates as a function of distance within the HFC cableplant of FIG. 5.

FIG. 8 is a functional block diagram illustrating an exemplary generalconfiguration of a network node apparatus according to the presentdisclosure.

FIG. 8a is a functional block diagram illustrating an exemplaryimplementation of the network node apparatus according to the presentdisclosure, configured for 3GPP 4G and 5G capability.

FIG. 8b is a graphical representation of frequency spectrum allocationsaccording to prior art LTE/LTE-A and 5G NR standards.

FIG. 8c is a graphical representation of a frequency spectrum allocationaccording to one embodiment of the present disclosure.

FIG. 9 is a functional block diagram illustrating an exemplary generalconfiguration of a CPEe apparatus according to the present disclosure.

FIG. 9a is a functional block diagram illustrating an exemplaryimplementation of a CPEe apparatus according to the present disclosure,configured for 3GPP 4G and 5G capability.

FIG. 9b is a functional block diagram illustrating another exemplaryimplementation of a CPEe apparatus according to the present disclosure,including IoT gateway functionality.

FIG. 10a is a functional block diagram illustrating an exemplary generalconfiguration of a standalone IoTG apparatus according to the presentdisclosure.

FIG. 10b is a functional block diagram illustrating an exemplaryimplementation of the standalone IoTG apparatus of FIG. 10 a.

FIG. 11 is a functional block diagram illustrating an exemplary generalconfiguration of a mobile client device with IoTG control and interfacecapability, according to the present disclosure.

FIG. 12a is a functional block diagram illustrating a first exemplarynetwork architecture for IoTG connectivity with the mobile device ofFIG. 11.

FIG. 12b is a functional block diagram illustrating a second exemplarynetwork architecture for IoTG connectivity with the mobile device ofFIG. 11.

FIGS. 13a and 13b illustrate first exemplary NSA (non-standalone)architectures over which embedded LTE channels can be utilized accordingto the present disclosure.

FIGS. 14a and 14b illustrate exemplary NSA (non-standalone)architectures over which embedded LTE channels can be utilized forprovision of IoT services, according to the present disclosure.

FIGS. 15a and 15b illustrate other exemplary NSA (non-standalone)architectures over which embedded LTE channels can be utilized forprovision of IoT services, according to the present disclosure.

FIG. 16a is a graphical representation of frequency bands associatedwith prior art IEEE Std. 802.15.4 and Bluetooth Low Energy (BLE)wireless interfaces.

FIG. 16b is a graphical representation of frequency bands associatedwith prior art IEEE Std. 802.15.4 and Wi-Fi wireless interfaces.

FIG. 17 depicts a frequency domain representation of an exemplary IoTchannel within the coax RF distribution network.

FIG. 18 depicts another frequency domain representation wherein the IoTchannel occupies an otherwise unused portion of the RF distributionnetwork, and is then frequency translated (upconverted/downconverted) tothe desired carrier frequency.

FIGS. 19a-c depict various implementations of one or more in-band IoTchannels within one or more LTE channels, according to the presentdisclosure.

FIG. 20 depicts a frequency domain representation of an LTE channelwithin the coax RF distribution network.

FIG. 21 depicts another frequency domain representation where the LTEchannel occupies an otherwise unused portion of the RF distributionnetwork and the IoT portion is selectively filtered and then frequencytranslated to the desired carrier frequency.

FIG. 22 is a logical flow diagram illustrating one embodiment of ageneralized method of utilizing an existing network (e.g., HFC) forcommand and control data communication.

FIG. 22a is a logical flow diagram illustrating one particularimplementation of waveform generation and transmission according to thegeneralized method of FIG. 22.

FIG. 22b is a logical flow diagram illustrating one particularimplementation of content reception and digital processing by a CPEeaccording to the generalized method of FIG. 22.

FIG. 23 is a logical flow diagram illustrating one embodiment of ageneralized method of utilizing an existing network (e.g., HFC) for IoTdata services to either a CPEe or IoT device endpoint, according to thepresent disclosure.

FIG. 23a is a logical flow diagram illustrating one particularimplementation of waveform generation and transmission according to thegeneralized method of FIG. 23.

FIG. 23b is a logical flow diagram illustrating one particularimplementation of content reception and digital processing by a receiver(e.g., CPEe) according to the generalized method of FIG. 23.

FIG. 23c is a logical flow diagram illustrating another implementationof content reception and transmission within a premises by a CPEeaccording to the generalized method of FIG. 23.

All figures © Copyright 2017-2019 Charter Communications Operating, LLC.All rights reserved.

DETAILED DESCRIPTION

Reference is now made to the drawings wherein like numerals refer tolike parts throughout.

As used herein, the term “application” (or “app”) refers generally andwithout limitation to a unit of executable software that implements acertain functionality or theme. The themes of applications vary broadlyacross any number of disciplines and functions (such as on-demandcontent management, e-commerce transactions, brokerage transactions,home entertainment, calculator etc.), and one application may have morethan one theme. The unit of executable software generally runs in apredetermined environment; for example, the unit could include adownloadable Java Xlet™ that runs within the JavaTV™ environment.

As used herein, the term “central unit” or “CU” refers withoutlimitation to a centralized logical node within a wireless networkinfrastructure. For example, a CU might be embodied as a 5G/NR gNBCentral Unit (gNB-CU), which is a logical node hosting RRC, SDAP andPDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB thatcontrols the operation of one or more gNB-DUs, and which terminates theF1 interface connected with one or more DUs (e.g., gNB-DUs) definedbelow.

As used herein, the terms “client device” or “user device” or “UE”include, but are not limited to, set-top boxes (e.g., DSTBs), gateways,modems, personal computers (PCs), and minicomputers, whether desktop,laptop, or otherwise, and mobile devices such as handheld computers,PDAs, personal media devices (PMDs), tablets, “phablets”, smartphones,and vehicle infotainment systems or portions thereof.

As used herein, the term “computer program” or “software” is meant toinclude any sequence or human or machine cognizable steps which performa function. Such program may be rendered in virtually any programminglanguage or environment including, for example, C/C++, Fortran, COBOL,PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML,VoXML), and the like, as well as object-oriented environments such asthe Common Object Request Broker Architecture (CORBA), Java™ (includingJ2ME, Java Beans, etc.) and the like.

As used herein, the term “distributed unit” or “DU” refers withoutlimitation to a distributed logical node within a wireless networkinfrastructure. For example, a DU might be embodied as a 5G/NR gNBDistributed Unit (gNB-DU), which is a logical node hosting RLC, MAC andPHY layers of the gNB or en-gNB, and its operation is partly controlledby gNB-CU (referenced above). One gNB-DU supports one or multiple cells,yet a given cell is supported by only one gNB-DU. The gNB-DU terminatesthe F1 interface connected with the gNB-CU.

As used herein, the term “DOCSIS” refers to any of the existing orplanned variants of the Data Over Cable Services InterfaceSpecification, including for example DOCSIS versions 1.0, 1.1, 2.0, 3.0and 3.1.

As used herein, the term “headend” or “backend” refers generally to anetworked system controlled by an operator (e.g., an MSO) thatdistributes programming to MSO clientele using client devices, orprovides other services such as high-speed data delivery and backhaul.

As used herein, the terms “Internet” and “internet” are usedinterchangeably to refer to inter-networks including, withoutlimitation, the Internet. Other common examples include but are notlimited to: a network of external servers, “cloud” entities (such asmemory or storage not local to a device, storage generally accessible atany time via a network connection, and the like), service nodes, accesspoints, controller devices, client devices, etc.

As used herein, the term “IoT device” refers without limitation toelectronic devices having one or more primary functions and beingconfigured to provide and/or receive data via one or more communicationprotocols. Examples of IoT devices include security or monitoringsystems, appliances, consumer electronics, vehicles, infrastructure(e.g., traffic signaling systems), and medical devices, as well asreceivers, hubs, proxy devices, or gateways used in associationtherewith.

As used herein, the term “IoT network” refers without limitation to anylogical, physical, or topological connection or aggregation of two ormore IoT devices (or one IoT device and one or more non-IoT devices).Examples of IoT networks include networks of one or more IoT devicesarranged in a peer-to-peer (P2P), star, ring, tree, mesh, master-slave,and coordinator-device topology.

As used herein, the term “LTE” refers to, without limitation and asapplicable, any of the variants or Releases of the Long-Term Evolutionwireless communication standard, including LTE-U (Long Term Evolution inunlicensed spectrum), LTE-LAA (Long Term Evolution, Licensed AssistedAccess), LTE-A (LTE Advanced), 4G LTE, WiMAX, VoLTE (Voice over LTE),and other wireless data standards.

As used herein the terms “5G” and “New Radio (NR)” refer withoutlimitation to apparatus, methods or systems compliant with 3GPP Release15, and any modifications, subsequent Releases, or amendments orsupplements thereto which are directed to New Radio technology, whetherlicensed or unlicensed.

As used herein, the term “memory” includes any type of integratedcircuit or other storage device adapted for storing digital dataincluding, without limitation, ROM, PROM, EEPROM, DRAM, SDRAM, DDR/2SDRAM, EDO/FPMS, RLDRAM, SRAM, “flash” memory (e.g., NAND/NOR), 3Dmemory, and PSRAM.

As used herein, the terms “microprocessor” and “processor” or “digitalprocessor” are meant generally to include all types of digitalprocessing devices including, without limitation, digital signalprocessors (DSPs), reduced instruction set computers (RISC),general-purpose (CISC) processors, microprocessors, gate arrays (e.g.,FPGAs), PLDs, reconfigurable computer fabrics (RCFs), array processors,secure microprocessors, and application-specific integrated circuits(ASICs). Such digital processors may be contained on a single unitary ICdie, or distributed across multiple components.

As used herein, the terms “MSO” or “multiple systems operator” refer toa cable, satellite, or terrestrial network provider havinginfrastructure required to deliver services including programming anddata over those mediums.

As used herein, the terms “MNO” or “mobile network operator” refer to acellular, satellite phone, WMAN (e.g., 802.16), or other network serviceprovider having infrastructure required to deliver services includingwithout limitation voice and data over those mediums. The term “MNO” asused herein is further intended to include MVNOs, MNVAs, and MVNEs.

As used herein, the terms “network” and “bearer network” refer generallyto any type of telecommunications or data network including, withoutlimitation, hybrid fiber coax (HFC) networks, satellite networks, telconetworks, and data networks (including MANs, WANs, LANs, WLANs,internets, and intranets). Such networks or portions thereof may utilizeany one or more different topologies (e.g., ring, bus, star, loop,etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeterwave, optical, etc.) and/or communications technologies or networkingprotocols (e.g., SONET, DOCSIS, IEEE Std. 802.3, ATM, X.25, Frame Relay,3GPP, 3GPP2, LTE/LTE-A/LTE-U/LTE-LAA, 5GNR, WAP, SIP, UDP, FTP,RTP/RTCP, H.323, etc.).

As used herein the terms “5G” and “New Radio (NR)” refer withoutlimitation to apparatus, methods or systems compliant with 3GPP Release15, and any modifications, subsequent Releases, or amendments orsupplements thereto which are directed to New Radio technology, whetherlicensed or unlicensed.

As used herein, the term “QAM” refers to modulation schemes used forsending signals over e.g., cable or other networks. Such modulationscheme might use any constellation level (e.g. QPSK, 16-QAM, 64-QAM,256-QAM, etc.) depending on details of a network. A QAM may also referto a physical channel modulated according to the schemes.

As used herein, the term “server” refers to any computerized component,system or entity regardless of form which is adapted to provide data,files, applications, content, or other services to one or more otherdevices or entities on a computer network.

As used herein, the term “storage” refers to without limitation computerhard drives, DVR device, memory, RAID devices or arrays, optical media(e.g., CD-ROMs, Laserdiscs, Blu-Ray, etc.), or any other devices ormedia capable of storing content or other information.

As used herein, the term “Wi-Fi” refers to, without limitation and asapplicable, any of the variants of IEEE Std. 802.11 or related standardsincluding 802.11 a/b/g/n/s/v/ac/ax, 802.11-2012/2013 or 802.11-2016, aswell as Wi-Fi Direct (including inter alia, the “Wi-Fi Peer-to-Peer(P2P) Specification”, incorporated herein by reference in its entirety).

Overview

In one exemplary aspect, the present disclosure provides improvedarchitectures, methods and apparatus for providing IoT data serviceswhich, inter alia, leverage existing managed network (e.g., cablenetwork) infrastructure, while also providing support and in some casesutilizing the 3GPP requisite “NSA” functionality. The disclosedarchitectures and apparatus enable, among other things, delivery of IoTdata services in a unified manner via a common “portal” or IoT gateway(IoTG) which may be both remotely accessed by a user, and remotelycontrolled/configured by the host network operator (e.g., MSO).

Also disclosed are the ability to control nodes within the network(including the enhanced CPEe endpoints described herein) via embeddedcontrol channels, some of which “repurpose” requisite 3GPP NSAinfrastructure such as LTE anchor channels. In one variant, the premisesdevices include RF-enabled receivers (enhanced consumer premisesequipment, or CPEe) configured to receive (and transmit) OFDM waveformsvia a coaxial cable drop to the premises, and interface with theaforementioned IoTG to enable provision of both 5G high-speed dataservices and lower bandwidth IoT services to the premises, all via asingle coaxial cable drop in the exemplary embodiment.

In one approach, the NSA LTE channels required for transmission of IoTuser data (and control/management data) to one or more premises devicesare leveraged, with the premises devices include RF-enabled IoT end userdevices configured to receive (and transmit) wireless signals to andfrom the IoTG at the premises, such as via one or more IoT wirelessinterfaces such as BLE, LoRA or IEEE Std. 802.15.4 interfaces. In thisfashion, heterogeneous interfaces (e.g., 3GPP and non-3GPP) commonlyfound in IoT devices can be aggregated via a common MSO interface to theHFC infrastructure (and beyond).

In one variant, the premises devices include RF-enabled receiversconfigured to receive (and transmit) OFDM waveforms via the coaxialcable drop to the premises, and this acts in effect as a “distributedantenna system” for the IoT devices at the premises. IoT traffic may bepositioned e.g., at an unused portion of the RF spectrum carried by thecoaxial distribution network, and depending on the available spectrum atthe premises used by the IoT user devices, eitherupconverted/downconverted to a desired carrier (and radiated at thepremises) and distributed by the IoT gateway, or simply “passed through”at the transmission frequency by the receiving CPEe.

Detailed Description of Exemplary Embodiments

Exemplary embodiments of the apparatus and methods of the presentdisclosure are now described in detail. While these exemplaryembodiments are described in the context of the previously mentionedwireless access nodes (e.g., gNBs and eNBs) associated with or supportedat least in part by a managed network of a service provider (e.g., MSO),other types of radio access technologies (“RATs”), other types ofnetworks and architectures that are configured to deliver digital data(e.g., text, images, games, software applications, video and/or audio)may be used consistent with the present disclosure. Such other networksor architectures may be broadband, narrowband, or otherwise, thefollowing therefore being merely exemplary in nature.

It will also be appreciated that while described generally in thecontext of a network providing service to a customer or consumer or enduser or subscriber (i.e., within a prescribed service area, venue, orother type of premises), the present disclosure may be readily adaptedto other types of environments including, e.g., commercial/retail, orenterprise domain (e.g., businesses), or even governmental uses. Yetother applications are possible.

Other features and advantages of the present disclosure will immediatelybe recognized by persons of ordinary skill in the art with reference tothe attached drawings and detailed description of exemplary embodimentsas given below.

Service Provider Network Architecture—

Referring now to FIG. 5, one embodiment of an enhanced service providernetwork architecture 500 is shown and described in detail.

As illustrated, the architecture 500 includes one or more hubs 505within the MSO network (e.g., whether near edge portions of the network,or further towards the core), including a 5G NR core (5GC) 503. The hub505 includes a WLAN controller process 515, and services one or more“enhanced” nodes 501, which each include a gNB CUe 504 and a networkradio node 509, described in greater detail below. The nodes 501 utilizeHFC infrastructure, including N-way taps 512 to deliver RF waveforms tothe various served premises (including the enhanced CPE or CPEe) 513 andultimately the user device(s) 507 (e.g., 3GPP-enabled UEs).

Also serviced by the node 501 are one or more non-CUe enabled nodes 511including 4G/4.5G/5G enabled network radio nodes 509, which serviceadditional premises as shown.

In the illustrated embodiment, the nodes 501, 511 are backhauled byoptical fiber, although this is merely illustrative, as other types ofbackhauls including e.g., high-bandwidth wireless may be used consistentwith the present disclosure.

Similarly, one or more pole-mounted radio nodes 506 a (and potentiallyother mobile client devices enabled for DU-type functionalities; e.g.,authorized to receive data from another node or client device, andbroadcast/receive signals according to the user domain frequency band)are backhauled to the MSO network via optical fiber (or other medium);these nodes 506 provide, inter alia, supplemental capacity/coverage forboth indoor and outdoor (and mobility) scenarios as described in greaterdetail in co-owned and co-pending U.S. patent application Ser. No.16/261,234 entitled “APPARATUS AND METHODS FOR ENABLING MOBILITY OF AUSER DEVICE IN AN ENHANCED WIRELESS NETWORK,” previously incorporatedherein.

In one exemplary embodiment, radio nodes 506 a are located on an “edge”of a network (i.e., functioning as a network node proximate to thepremises and away from the core), and are enabled for 4G and/or 5Gcommunications as described in greater detail below. A given DUe thatprovides 5G coverage to the premises thereby supplements the ultra-lowlatency and high-bandwidth services by the CUe 504. Moreover, asdescribed further below, the CUe may be logically and functionallygrouped with one or more DUe's 506 to together make up a gNB. Prescribedunlicensed and/or licensed frequency bands are utilized by the nodes 506a. For example, in one implementation, the disclosed solution supportsone or more prescribed subsets of NR and NR-U band combinations asdefined by 3GPP, depending on the particular application(s) anticipatedby the installation and the locale in which it is installed (includingfor example whether other operators or carriers such as MNOs areutilizing licensed spectrum within the prescribed area, and whichfrequency bands such operators are using). It will also be appreciatedthat so-called “quasi-licensed” spectrum (such as for instance thatwithin the 3.55-3.70 GHz CBRS bands in the U.S.) may be utilizedconsistent with the methods and apparatus described herein.

In one variant, as noted above, mobile devices may function asintermediary nodes or transient “jumping points.” Such devices may bethose owned by subscribers of the hub or core providing the managednetwork services who have opted into (or not opted out) of use of theireligible devices as nodes. In other variants, devices owned bysubscribers of a different core (e.g., managed by a different entity)may be included in the network of nodes. As an aside, such networkingschemes are often generally referred to as “fog networking,” adecentralized computing infrastructure in which data, computations,storage, and applications are distributed in an efficient manner betweenthe data source and the destination (e.g., a “cloud” server, premisesequipment, end user device) as opposed to a more highly centralizedarchitecture.

A Wi-Fi router device 517 is also present in the served premises toprovide WLAN coverage, in conjunction with the controller 515 at the hub505. The centralized Wi-Fi controller 515 is also utilized in theexemplary architecture 500 for tight-interworking and better mobilitybetween the 3GPP and Wi-Fi access technologies where the Wi-Fi router iseither integrated with the consumer premises equipment (e.g., enhancedCPE or CPEe) or connected to it. In various embodiments, one or moreintermediary nodes (e.g., radio node 506 a) located between the CUe 504and the served premises are utilized to provide additional coverage andbandwidth to the premises. Then, mobility between the 3GPP and Wi-Fichannels for any user can be triggered for the best data throughput,such as based on (i) estimation of the RF quality of the Wi-Fi channeltoward the user, and/or (ii) the degree of congestion of the Wi-Firouter, and not just the Wi-Fi received signal strength indicators(RSSI) measured at the mobile device, the latter which may not berepresentative of the service quality that can be obtained by the user.Additional detail on the foregoing Wi-Fi related aspects is alsodescribed in greater detail in co-owned and co-pending U.S. patentapplication Ser. No. 16/261,234 entitled “APPARATUS AND METHODS FORENABLING MOBILITY OF A USER DEVICE IN AN ENHANCED WIRELESS NETWORK,”previously incorporated herein.

The architecture 500 also includes an IoTG (IoT gateway) functionality,as described in greater detail subsequently herein. The IoTG 519 is indata communication with the CPEe 513 (and as discussed below, may alsobe integrated therein to varying degrees depending on the particularapplication), as well as a plurality of IoT-enabled end devices 556 a-cvia for example the various air interfaces of the IoTG 519.

The MSO network architecture 500 of FIG. 5 is particularly useful forthe delivery of packetized content (e.g., encoded digital contentcarried within a packet or frame structure or protocol) consistent withthe various aspects of the present disclosure. In addition to on-demandand broadcast content (e.g., live video programming), the system of FIG.5 may deliver Internet data and OTT (over-the-top) services to the endusers (including those of the DUe's 506 a) via the Internet protocol(IP) and TCP (i.e., over the 5G radio bearer), although other protocolsand transport mechanisms of the type well known in the digitalcommunication art may be substituted.

The architecture 500 of FIG. 5 further provides a consistent andseamless user experience with IPTV over both wireline and wirelessinterfaces. Additionally, in the IP paradigm, dynamic switching betweenunicast delivery and multicast/broadcast is used based on e.g., localdemand. For instance, where a single user (device) is requestingcontent, an IP unicast can be utilized. For multiple devices (i.e., withmultiple different IP addresses, such as e.g., different premises),multicast can be utilized. This approach provides for efficient andresponsive switching of delivery and obviates other moreequipment/CAPEX-intensive approaches.

Moreover, the architecture can be used for both broadband data deliveryas well as “content” (e.g., movie channels) simultaneously, and obviatesmuch of the prior separate infrastructure for “in band” and DOCSIS (andOOB) transport. Specifically, with DOC SIS (even FDX DOCSIS), bandwidthis often allocated for video QAMs, and a “split” is hard-coded fordownstream and upstream data traffic. This hard split is typicallyimplemented across all network elements—even amplifiers. In contrast,under the exemplary configuration of the architecture disclosed herein,effectively all traffic traversing the architecture is IP-based, andhence in many cases there is no need to allocate QAMs and frequencysplits for different program or data streams. This “all-IP” approachenables flexible use of the available bandwidth on the transmissionmedium for all applications dynamically, based on for instance thedemand of each such application at any given period or point in time.

In certain embodiments, the service provider network 500 alsoadvantageously permits the aggregation and/or analysis of subscriber- oraccount-specific data (including inter alia, correlation of particularCUe or DUe or E-UTRAN eNB/femtocell devices associated with suchsubscriber or accounts) as part of the provision of services to usersunder the exemplary delivery models described herein. As but oneexample, device-specific IDs (e.g., gNB ID, Global gNB Identifier, NCGI,MAC address or the like) can be cross-correlated to MSO subscriber datamaintained at e.g., the network head end(s) 507 so as to permit or atleast facilitate, among other things, (i) user/device authentication tothe MSO network; (ii) correlation of aspects of the area, premises orvenue where service is provided to particular subscriber capabilities,demographics, or equipment locations, such as for delivery oflocation-specific or targeted content or advertising or 5G “slicing”configuration or delivery; and (iii) determination of subscriptionlevel, and hence subscriber privileges and access to certain services asapplicable.

Moreover, device profiles for particular devices (e.g., 3GPP 5G NR andWLAN-enabled UE, or the CPEe 513 and any associated antenna 516, etc.)can be maintained by the MSO, such that the MSO (or its automated proxyprocesses) can model the device for wireless or other capabilities. Forinstance, one (non-supplemented) CPEe 513 may be modeled as havingbandwidth capability of X Gbps, while another premises' supplementedCPEe may be modeled as having bandwidth capability of X+Y Gbps, andhence the latter may be eligible for services or 3GPP NR “slices” thatare not available to the former.

Referring now to FIG. 5a , one embodiment of a premises sidearchitecture 550 is shown and described. As illustrated, thearchitecture 550 is disposed at a premises 551, such as at a customerhome or enterprise. The architecture includes a CPEe 513 serviced viaboth (i) a coaxial cable drop from the host HFC network, (ii) asupplemental RF link 516 of the type previously described with respectto FIG. 5, and IoTG 519. Also included is a WLAN router/interface 517.

Also served by the IoTG 519 are three IoT devices 556 (556 a, 556 b, and556 c). The first IoT device 556 a is shown as having user plane dataconnectivity only (e.g., via a wired interface such as Cat-5, USB, etc.,or wireless); i.e., the IoTG or CPEe 513 acts as the logical 3GPPendpoint “proxy” for the IoT device 556 a, and recovers and transactsthe user plane data to/from the IoT device 556 a. This allows, interalia, the IoT device 556 a to be highly simplified, in that it does notneed to have an MSO/3GPP “stack” or related functionality so that theIoT device itself can act as a 3GPP endpoint.

In contrast, the second IoT device 556 b is shown as having user planedata connectivity and control plane connectivity (e.g., via a wiredinterface such as Cat-5, USB, or wireless); i.e., the IoTG 519 or CPEe513 acts as merely a logical pass-through for the IoT device 556 b(contrast: frequency pass-through as described elsewhere herein), andtransacts the user plane and control plane data to/from the IoT device556 b without implementing these functions itself. This allows, interalia, the IoT device 556 b to be controlled remotely, and implementgreater functionality than could be achieved using the first IoT device556 a. The second IoT device 556 b also includes a 3GPP (or non-3GPP)IoT stack such that it can act as the logical endpoint for the IoT datachannels being terminated at the premises 551; the CPEeupconverts/downconverts the received waveforms from the HFC network tothe required IoT device 556 b carrier (e.g., consistent with an RFwireline or air interface maintained by the second IoT device 556 b),and distributes them via the IoTG 519. The IoT device 556 b demodulatesand recovers the user and control plane data indigenously.

The third IoT device 556 c is shown as having user plane dataconnectivity and control plane connectivity (e.g., via a wired interfacesuch as Cat-5, USB, or wireless); i.e., the CPEe 513 acts as merely alogical pass-through for the IoT device 556 c, as well as a frequencypass-through as described elsewhere herein, and transacts the user planeand control plane data to/from the IoT device 556 c without implementingthese functions itself for the IoT device. This allows, inter alia, theIoT device 556 c to be controlled remotely, and implement greaterfunctionality than could be achieved using the first IoT device 556 a.The third IoT device 556 c again includes a 3GPP (or non-3GPP) IoT stacksuch that it can act as the logical endpoint for the IoT data channelsbeing terminated at the premises 551; however, rather than the CPEeupconverting/downconverting the received waveforms from the HFC networkto the required IoT device 556 c carrier (e.g., consistent with an RFwireline or air interface maintained by the third IoT device 556 c), andCPEe 513 merely acts as an RF pass-through of the IoT channel(s) whichare transmitted by the transmitting node 509 at carrier to the IoTdevice 556 c, via the repeater antennae and port of the CPEe (seediscussion of FIGS. 9 and 9 a below). The third IoT device 556 cdemodulates and recovers the user and control plane data indigenously.

The architecture 550 of FIG. 5a advantageously allows, inter alia,separate placement of the WLAN router, IoTG, and CPEe (with repeaters)within the premises so as to optimize their operation (e.g., so as toput each in the best position relative to served user devices). It willalso be appreciated that wireless links of sufficient bandwidth betweenthe CPEe 513 and the IoTG 519 and/or WLAN router 517 may also beutilized for backhaul (e.g., so as to obviate wires or cables betweenthe devices). For instance, the 5G premises user band and associated airinterface of the CPEe may be used as the backhaul for these otherdistributed devices.

FIG. 5b is a functional block diagram of a second exemplary premisesnetwork architecture 570 comprising the IoTG 519 described hereincombined in a common form factor with the CPEe 513 and WLAN router 517,useful with the MSO architecture 500 of FIG. 5. This approach has theadvantage of allowing a “one box” solution for a given premisesproviding each of: (i) high-speed 5G data services; (ii) 5G mobility,(iii) WLAN connectivity, and (iv) PAN (e.g., IoT) data connectivity andmanagement.

See the discussions of FIGS. 17-21 below for various schemes for RFspectrum allocation useful with the architecture of FIGS. 5-5 b.

As a brief aside, the 5G technology defines a number of networkfunctions (NFs), which include the following:

1. Access and Mobility Management function (AMF)—Provides fortermination of NAS signaling, NAS integrity protection and ciphering,registration and connection and mobility management, accessauthentication and authorization, and security context management. TheAMF has functions analogous to part of the MME functionality of theprior Evolved Packet Core (EPC).

2. Application Function (AF)—Manages application influence on trafficrouting, accessing NEF, interaction with policy framework for policycontrol. The NR AF is comparable to the AF in EPC.

3. Authentication Server Function (AUSF)—Provides authentication serverfunctionality. The AUSF is similar to portions of the HSS from EPC.

4. Network Exposure function (NEF)—Manages exposure of capabilities andevents, secure provision of information from external applications to3GPP network, translation of internal/external information. The NEF is awholly new entity as compared to EPC.

5. Network Slice Selection Function (NSSF)—Provides for selection of theNetwork Slice instances to serve the UE, determining the allowed NSSAI,determining the AMF set to be used to serve the UE. The NSSF is a whollynew entity as compared to EPC.

6. NF Repository function (NRF)—Supports the service discovery function,maintains NF profile and available NF instances The NRF is a wholly newentity as compared to EPC.

7. Policy Control Function (PCF)—Provides a unified policy framework,providing policy rules to CP functions, and access subscriptioninformation for policy decisions in UDR. The PCF has part of the PCRFfunctionality from EPC.

8. Session Management function (SMF)—Provides for session management(session establishment, modification, release), IP address allocation &management for UEs, DHCP functions, termination of NAS signaling relatedto session management, DL data notification, traffic steeringconfiguration for UPF for proper traffic routing. The SMF includesportions of the MME and PGW functionality from EPC.

9. Unified Data Management (UDM)—Supports generation of Authenticationand Key Agreement (AKA) credentials, user identification handling,access authorization, subscription management. This comprises a portionof HSS functionality from EPC.

10. User plane function (UPF)—The UPF provides packet routing &forwarding, packet inspection, QoS handling, and also acts as anexternal PDU session point of interconnect to Data Network (DN). The UPFmay also act as an anchor point for intra-RAT and inter-RAT mobility.The UPF includes some of the prior SGW and PGW functionality from EPC.

Within the 5G NR architecture, the control plane (CP) and user plane(UP) functionality is divided within the core network or NGC (NextGeneration Core). For instance, the 5G UPF discussed above supports UPdata processing, while other nodes support CP functions. This dividedapproach advantageously allows for, inter alia, independent scaling ofCP and UP functions. Additionally, network slices can be tailored tosupport different services, such as for instance those described hereinwith respect to session handover between e.g., WLAN and 3GPP NR, andsupplemental links to the CPEe.

In addition to the NFs described above, a number of differentidentifiers are used in the NG-RAN architecture, including those of UE'sand for other network entities, and may be assigned to various entitiesdescribed herein. Specifically:

-   -   the AMF Identifier (AMF ID) is used to identify an AMF (Access        and Mobility Management Function);    -   the NR Cell Global Identifier (NCGI), is used to identify NR        cells globally, and is constructed from the PLMN identity to        which the cell belongs, and the NR Cell Identity (NCI) of the        cell;    -   the gNB Identifier (gNB ID) is used to identify gNBs within a        PLMN, and is contained within the NCI of its cells;    -   the Global gNB ID, which is used to identify gNBs globally, and        is constructed from the PLMN identity to which the gNB belongs,        and the gNB ID;    -   the Tracking Area identity (TAI), which is used to identify        tracking areas, and is constructed from the PLMN identity to        which the tracking area belongs, and the TAC (Tracking Area        Code) of the Tracking Area; and    -   the Single Network Slice Selection Assistance information        (S-NSSAI), which is used to identify a network slice.

Hence, depending on what data is useful to the MSO or its customers,various portions of the foregoing can be associated and stored toparticular gNB “clients” or their components being backhauled by the MSOnetwork.

Distributed gNB Architectures

In the context of FIG. 5, the DUe's described herein may assume anynumber of forms and functions relative to the enhanced CPE (CPEe) 513and the radio node 506 a (e.g., pole mounted external device).Recognizing that generally speaking, “DU” and “CU” refer to 3GPPstandardized features and functions, these features and functions can,so long as supported in the architecture 500 of FIG. 5, be implementedin any myriad number of ways and/or locations. Moreover, enhancementsand/or extensions to these components (herein referred to as CUe andDUe) and their functions provided by the present disclosure may likewisebe distributed at various nodes and locations throughout thearchitecture 500, the illustrated locations and dispositions beingmerely exemplary.

Notably, the “enhanced” NR-based gNB architecture utilizes existinginfrastructure (e.g., at least a portion of the extant HFC cablingcontrolled by an MSO such as the Assignee hereof) while expanding thefrequency spectrum used for signal propagation within the infrastructure(e.g., 1.6 GHz in total bandwidth). Moreover, access points or nodesinstalled at venues or premises, especially “edge”-based nodes (at leastsome of which may be controlled, licensed, installed, or leased by theMSO), may be leveraged to deliver 5G-based services to a subscriber ofthe 5G NR Core (e.g., 503). Fog-based networking made possible throughthis leveraged infrastructure allows the subscriber to access receiveand maintain 5G service whether indoor or outdoor, and in fact, evenwhile the subscriber is changing locations, e.g., moving indoor tooutdoor, outdoor to indoor, between servicing nodes indoors (e.g.,within a large house, office or housing complex, or venue), and betweenservicing nodes outdoors. Other nodes may be leveraged, including other5G-enabled mobile devices that have opted into (or not opted out of)participating in the fog network. In effect, the ubiquity of mobiledevices creates a peer-to-peer network for distribution and delivery ofultra-low-latency (e.g., 1 ms ping) and ultra-high-speed (e.g., 10 Gbpsor higher) connectivity. In many cases, utilizing one or moreparticipating peer devices results in faster service (e.g., greatlyreduced ping) by obviating the need to reach a cell tower, a server, ora gateway that is resident in the backend portion of a cloud-typenetwork.

Notably, the principles described further below enable a subscriber tomaintain the 5G service (or any other 3GPP- or IEEE 802.11-basedconnectivity) without the signals dropping or disconnecting betweensessions. In other words, “seamless” transfer of connectivity betweennodes (akin to handovers) is made possible despite a difference in atleast a portion of wireless data communications standards that may beutilized by the nodes. For instance, a CPEe and a DUe disposed near the“edge” of the network (i.e., near consumer premises) may each be capableof communicating data with, e.g., a mobile user device, via either orboth 3GPP- and IEEE 802.11-based protocols. A subscriber, however, wouldnot require a reconnection process with a different base station ormodem (as opposed to, e.g., establishing connection to cellular dataservices when outside the range of a Wi-Fi AP, or connecting back to theWi-Fi AP when entering the premises), invoking a “seamless” feel andfurther increasing the user experience.

By virtue of the way the frequency spectra used in existinginfrastructure is accessed, such enhanced gNB architecture providessalient advantages to a subscriber thereof, such as improvedconnectivity speeds (e.g., data rates, response times, latency) andseamless mobility of user devices, thus significantly improving userexperience relative to currently available services. Further, theoperator of such an architecture may advantageously save costs ofconnecting new cables and pipes across long distances by obviating theneed to overhaul the infrastructure itself.

Accordingly, referring now to FIGS. 6a-6f , various embodiments of thedistributed (CUe/DUe) gNB architecture according to the presentdisclosure are described. As shown in FIG. 6a , a first architecture 620includes a gNB 501 having an enhanced CU (CUe) 504 and a plurality ofenhanced DUs (DUe) 506, 506 a. As described in greater detailsubsequently herein, these enhanced entities are enabled to permitinter-process signaling and high data rate, low latency services,whether autonomously or under control of another logical entity (such asthe NG Core 503 with which the gNB communicates, or components thereof),as well as unified mobility and IoT services.

The individual DUe's 506, 506 a in FIG. 6a communicate data andmessaging with the CUe 504 via interposed physical communicationinterfaces 628 and logical interfaces 630. As previously described, suchinterfaces may include a user plane and control plane, and be embodiedin prescribed protocols such as F1AP. Operation of each DUe and CUe aredescribed in greater detail subsequently herein; however, it will benoted that in this embodiment, one CUe 504 is associated with one ormore DUe's 506, 506 a, yet a given DUe is only associated with a singleCUe. Likewise, the single CUe 504 is communicative with a single NG Core503, such as that operated by an MSO. Each NG Core may have multiplegNBs 501 associated therewith (e.g., of the type shown in FIG. 5).

In the architecture 640 of FIG. 6b , two or more gNBs 501 a-n arecommunicative with one another via e.g., an Xn interface 627, andaccordingly can conduct at least CUe to CUe data transfer andcommunication. Separate NG Cores 503 a-n are used for control and userplane (and other) functions of the network.

In the architecture 660 of FIG. 6c , two or more gNBs 501 a-n arecommunicative with one another via e.g., the Xn interface 627, andaccordingly can conduct at least CUe to CUe data transfer andcommunication. Moreover, the separate NG Cores 503 a-n are logically“cross-connected” to the gNBs 501 of one or more other NG Cores, suchthat one core can utilize/control the infrastructure of another, andvice versa. This may be in “daisy chain” fashion (i.e., one gNB iscommunicative one other NG Core other than its own, and that NG Core iscommunicate with yet one additional gNB 501 other than its own, and soforth), or the gNBs and NG Cores may form a “mesh” topology wheremultiple Cores 503 are in communication with multiple gNBs or multipledifferent entities (e.g., service providers). Yet other topologies willbe recognized by those of ordinary skill given the present disclosure.This cross-connection approach advantageously allows for, inter alia,sharing of infrastructure between two MSOs, or between MNO and MSO,which is especially useful in e.g., dense deployment environments whichmay not be able to support multiple sets of RAN infrastructure, such asfor different service providers.

FIGS. 6e-6f relate to so-called NSA architectures contemplated during,inter alia, migration or transition between 4G/4.5G and 5G technology.Note that per 3GPP Release 15, some new definitions of entities havebeen introduced, including: (i) LTE eNB—An eNB device that can connectto the EPC and the extant pre-Release 15 LTE core network; (ii) eLTEeNB—An evolution of the LTE eNB—the eLTE eNB can connect to the EPC andthe 5GC; (iii) NG—A data interface between the NGC and the gNB; (iv)NG2—A control plane (CP) interface between core network and the RAN(corresponding to S1-C in LTE); and (v) NG3—A user plane (UP) interfacebetween the core network and the RAN (corresponding to S1-U in LTE).

In a “standalone” or SA scenario (e.g., FIG. 6a-6c above), the 5G NR orthe evolved LTE radio cells and the core network are operated alone, andare used for both control plane and user plane. The SA configuration ismore simplified than NSA from an operational and management standpoint.Moreover, pure SA networks can operate independently using normalinter-generation handover between 4G and 5G for service continuity.Three variations of SA are defined in 3GPP: (i) Option 1 using EPC andLTE eNB access (i.e. as per current 4G LTE networks); (ii) Option 2using 5GC and NR gNB access; and (iii) Option 5 using 5GC and LTE ng-eNBaccess.

As previously described with respect to FIGS. 3b-3d , in non-standalone(NSA) scenarios, the NR radio cells are effectively integrated orcombined with LTE radio cells using dual connectivity to provide radioaccess. In the case of NSA, the radio network core network may be eitherEPC or 5GC, depending on the particular choice of the operator.

FIG. 6d illustrates a gNB and eLTE eNB architecture including a 5G NRCore (NGC) according to the present disclosure. In this architecture670, the NG Core 503 communicates with the gNB 501 with CUe and DUe's,as well as supporting an eLTE eNB 316 for the user plane. Control planefunctions for the eLTE eNB are supported by the gNB 501.

FIG. 6e illustrates an NSA gNB and LTE eNB architecture including anEvolved Packet Core (EPC) according to the present disclosure. In thisarchitecture 680, an EPC (EP Core) 303, 333 communicates with the gNB501 with CUe and DUe's for user plane function, as well as supporting anLTE eNB 317 (i.e., an non-5G communicative NodeB) for the user plane andcontrol plane.

FIG. 6f illustrates an NSA gNB and eLTE eNB architecture including anEvolved Packet Core (EPC) according to the present disclosure. In thisarchitecture 690, an EPC (EP Core) 303, 333 communicates with the gNB501 with CUe and DUe's for user plane function, as well as supporting aneLTE eNB 316 (i.e., a 5G communicative NodeB) for the user plane andcontrol plane.

It will also be appreciated that while described primarily with respectto a unitary gNB-CUe entity or device 501 as shown in FIGS. 5 and 6 a-6f, the present disclosure is in no way limited to such architectures.For example, the techniques described herein may be implemented as partof a distributed or dis-aggregated or distributed CUe entity (e.g., onewherein the user plane and control plane functions of the CUe aredis-aggregated or distributed across two or more entities such as aCUe-C (control) and CUe-U (user)), and/or other functional divisions areemployed, including in NSA-based architectures.

It is also noted that heterogeneous architectures of eNBs or femtocells(i.e., E-UTRAN LTE/LTE-A Node B's or base stations, including eLTE eNBs316) and gNBs may be utilized consistent with the architectures of FIGS.5 and 6 a-6 f. For instance, a given DUe may (in addition to supportingnode operations as discussed in greater detail with respect to FIGS. 8-8a below), act (i) solely as a DUe (i.e., 5G NR PHY node) and operateoutside of an E-UTRAN macrocell, or (ii) be physically co-located withan eNB or femtocell and provide NR coverage within a portion of the eNBmacrocell coverage area, or (iii) be physically non-colocated with theeNB or femtocell, but still provide NR coverage within the macrocellcoverage area.

In accordance with the 5G NR model, the DUe(s) 506, 506 a compriselogical nodes that each may include varying subsets of the gNBfunctions, depending on the functional split option. DUe operation iscontrolled by the CUe 504 (and ultimately for some functions by the NGCore 303). Split options between the DUe and CUe in the presentdisclosure may include for example:

-   -   Option 1 (RRC/PCDP split)    -   Option 2 (PDCP/RLC split)    -   Option 3 (Intra RLC split)    -   Option 4 (RLC-MAC split)    -   Option 5 (Intra MAC split)    -   Option 6 (MAC-PHY split)    -   Option 7 (Intra PHY split)    -   Option 8 (PHY-RF split)

Under Option 1 (RRC/PDCP split), the RRC (radio resource control) is inthe CUe while PDCP (packet data convergence protocol), RLC (radio linkcontrol), MAC, physical layer (PHY) and RF are kept in the DUe, therebymaintaining the entire user plane in the distributed unit.

Under Option 2 (PDCP/RLC split), there are two possible variants: (i)RRC, PDCP maintained in the CUe, while RLC, MAC, physical layer and RFare in the DU(s); and (ii) RRC, PDCP in the CUe (with split user planeand control plane stacks), and RLC, MAC, physical layer and RF in theDUe's.

Under Option 3 (Intra RLC Split), two splits are possible: (i) splitbased on ARQ; and (ii) split based on TX RLC and RX RLC.

Under Option 4 (RLC-MAC split), RRC, PDCP, and RLC are maintained in theCUe 504, while MAC, physical layer, and RF are maintained in the DUe's.

Under Option 5 (Intra-MAC split), RF, physical layer and lower part ofthe MAC layer (Low-MAC) are in the DUe's 506, 506 a, while the higherpart of the MAC layer (High-MAC), RLC and PDCP are in the CUe 504.

Under Option 6 (MAC-PHY split), the MAC and upper layers are in the CUe,while the PHY layer and RF are in the DUe's. The interface between theCUe and DUe's carries data, configuration, and scheduling-relatedinformation (e.g. Modulation and Coding Scheme or MCS, layer mapping,beamforming and antenna configuration, radio and resource blockallocation, etc.) as well as measurements.

Under Option 7 (Intra-PHY split), different sub-options for UL (uplink)and DL downlink) may occur independently. For example, in the UL, FFT(Fast Fourier Transform) and CP removal may reside in the DUe's, whileremaining functions reside in the CUe 504. In the DL, iFFT and CPaddition may reside in the DUe, while the remainder of the PHY residesin the CUe.

Finally, under Option 8 (PHY-RF split), the RF and the PHY layer may beseparated to, inter alia, permit the centralization of processes at allprotocol layer levels, resulting in a high degree of coordination of theRAN. This allows optimized support of functions such as CoMP, MIMO, loadbalancing, and mobility.

Generally speaking, the foregoing split options are intended to enableflexible hardware implementations which allow scalable cost-effectivesolutions, as well as coordination for e.g., performance features, loadmanagement, and real-time performance optimization. Moreoverconfigurable functional splits enable dynamic adaptation to various usecases and operational scenarios. Factors considered in determininghow/when to implement such options can include: (i) QoS requirements foroffered services (e.g. low latency to support 5G RAN requirements, highthroughput); (ii) support of requirements for user density and loaddemand per given geographical area (which may affect RAN coordination);(iii) availability of transport and backhaul networks with differentperformance levels; (iv) application type (e.g. real-time or non-realtime); (v) feature requirements at the Radio Network level (e.g. CarrierAggregation).

It is also noted that the “DU” functionality referenced in the varioussplit options above can itself be split across the DUe and itsdownstream components, such as the RF stages of the node 509 (see FIGS.8 and 8 a) and/or the CPEe 513. As such, the present disclosurecontemplates embodiments where some of the functionality typically foundwithin the DUe may be distributed to the node/CPEe.

It will further be recognized that user-plane data/traffic may also berouted and delivered apart from the CUe. In one implementation(described above), the CUe hosts both the RRC (control-plane) and PDCP(user-plane); however, as but one alternate embodiment, a so-called“dis-aggregated” CUe may be utilized, wherein a CUe-CP entity (i.e.,CUe—control plane) hosts only the RRC related functions, and a CUe-UP(CUe—user plane) which is configured to host only PDCP/SDAP (user-plane)functions. The CUe-CP and CUe-UP entities can, in one variant, interfacedata and inter-process communications via an E1 data interface, althoughother approaches for communication may be used.

It will also be appreciated that the CUe-CP and CUe-UP may be controlledand/or operated by different entities, such as where one serviceprovider or network operator maintains cognizance/control over theCUe-UP, and another over the CUe-CP, and the operations of the twocoordinated according to one or more prescribed operational or servicepolicies or rules.

Referring again to FIG. 5, the exemplary embodiment of the DUe 509 is astrand-mounted or buried DUe (along with the downstream radio chain(s),the latter which may include one or more partial or complete RRH's(remote radio heads) which include at least portions of the PHYfunctionality of the node (e.g., analog front end, DAC/ADCs, etc.). Ascan be appreciated, the location and configuration of each DUe/node maybe altered to suit operational requirements such as population density,available electrical power service (e.g., in rural areas), presence ofother closely located or co-located radio equipment, geographicfeatures, etc.

As discussed with respect to FIGS. 8-8 a below, the nodes 506, 506 a inthe embodiment of FIG. 5 include multiple OFDM-basedtransmitter-receiver chains of 800 MHz nominal bandwidth, although thisconfiguration is merely exemplary. In operation, the node generateswaveforms that are transmitted in the allocated band (e.g., up toapproximately 1.6 GHz), but it will be appreciated that if desired, theOFDM signals may in effect be operated in parallel with signals carriedin the below-800 MHz band, such as for normal cable system operations.

Referring again to FIG. 5, in one implementation, each node (and henceDUe) is in communication with its serving CUe via an F1 interface, andmay be either co-located or not co-located with the CUe. For example, anode/DUe may be positioned within the MSO HFC infrastructure proximate adistribution node within the extant HFC topology, such as before theN-way tap point 512, such that a plurality of premises (e.g., the shownresidential customers) can be served by the node/DUe via theaforementioned OFDM waveforms and extant HFC plant. In certainembodiments, each node/DUe 506, 506 a is located closer to the edge ofthe network, so as to service one or more venues or residences (e.g., abuilding, room, or plaza for commercial, corporate, academic purposes,and/or any other space suitable for wireless access). For instance, inthe context of FIG. 5, a node might even comprise a CPEe or externalaccess node (each discussed elsewhere herein). Each radio node 506 isconfigured to provide wireless network coverage within its coverage orconnectivity range for its RAT (e.g., 4G and/or 5G NR). For example, avenue may have a wireless NR modem (radio node) installed within theentrance thereof for prospective customers to connect to, includingthose in the parking lot via inter alia, their NR or LTE-enabledvehicles or personal devices of operators thereof.

Notably, different classes of DUe/node 506, 506 a may be utilized. Forinstance, a putative “Class A” LTE eNB may transmit up X dbm, while a“Class-B” LTE eNBs can transmit up to Y dbm (Y>X), so the average areacan vary widely. In practical terms, a Class-A device may have a workingrange on the order of hundreds of feet, while a Class B device mayoperate out to thousands of feet or more, the propagation and workingrange dictated by a number of factors, including the presence of RF orother interferers, physical topology of the venue/area, energy detectionor sensitivity of the receiver, etc. Similarly, different types ofNR-enabled nodes/DUe 506, 506 a can be used depending on these factors,whether alone or with other wireless PHYs such as WLAN, etc.

Moreover, using the architecture of FIG. 5, data may be deliveredredundantly or separately via the radio access node 506 a as well as theCPEe 513 via one or more DUe units 506 a, depending on the location ofthe client device 507, thereby enabling the client device to haveconstant access to the requested data when in range of the servingnode/device. For instance, in one scenario, the supplemental link isused to maintain a separate data session simultaneously even withoutmobility; i.e., one session via PHY1 for Service A, and anothersimultaneous session via PHY2 for Service B (as opposed to handover ofService A from PHY1 to PHY2). In one implementation, extant 3GPP LTE-Amulti-band carrier aggregation (CA) protocols are leveraged, wherein thesupplemental link acts as a Secondary Cell or “SCell” to the PrimaryCell or “PCell” presently serving the user from inside thehome/building, or vice versa (e.g., the supplemental link can act as thePCell, and the SCell added thereafter via e.g., the premises node). Seeinter alia, 3GPP TR 36.808, “Evolved Universal Terrestrial Radio Access(E-UTRA); Carrier Aggregation; Base Station (BS) radio transmission andreception,” incorporated herein by reference in its entirety.

Signal Attenuation and Bandwidth

FIGS. 7a and 7b illustrate exemplary downstream (DS) and upstream (US)data throughputs or rates as a function of distance within the HFC cableplant of FIG. 5. As illustrated, a total (DS and US combined) bandwidthon the order of 10 Gbps is achievable (based on computerized simulationconducted by the Assignee hereof), at Node+2 at 2100 ft (640 m), and atNode+1 at 1475 ft (450 m). One exemplary split of the aforementioned 10Gbps is asymmetric; e.g., 8 Gbps DL/2 Gbps UL, although this may bedynamically varied using e.g., TDD variation as described elsewhereherein.

Notably, the portions of the extant HFC architecture described above(see e.g., FIGS. 1 and 2) utilized by the architecture 500 of FIG. 5 arenot inherently limited by their medium and architecture (i.e., opticalfiber transport ring, with coaxial cable toward the edges); coaxialcable can operate at frequencies significantly higher than the sub-1 GHztypically used in cable systems, but at a price of significantlyincreased attenuation. As is known, the formula for theoreticalcalculation of attenuation (A) in a typical coaxial cable includes theattenuation due to conductors plus attenuation due to the dielectricmedium:

$\begin{matrix}{A = {{4.35\left( {R_{t}/Z_{0}} \right)} + {2{\sqrt{E}}_{78}{pF}}}} \\{= {{dB}\mspace{14mu}{per}\mspace{14mu} 100\mspace{14mu}{{ft}.}}}\end{matrix}$

where:

-   -   Rt=Total line resistance ohms per 1000 ft.    -   Rt=0.1 (1/d+1√{square root over (F)}_(D))    -   p=Power factor of dielectric    -   F=Frequency in megahertz (MHz)

As such, attenuation increases with increasing frequency, and hencethere are practical restraints on the upper frequency limit of theoperating band. However, these restraints are not prohibitive in rangesup to for example 2 GHz, where with suitable cable and amplifiermanufacturing and design, such coaxial cables can suitably carry RFsignals without undue attenuation. Notably, a doubling of the roughly800 MHz-wide typical cable RF band (i.e., to 1.6 GHz width) is verypossible without suffering undue attenuation at the higher frequencies.

It will also be appreciated that the attenuation described above is afunction of, inter alia, coaxial conductor length, and hence higherlevels of “per-MHz” attenuation may be acceptable for shorter runs ofcable. Stated differently, nodes serviced by shorter runs of cable maybe able to better utilize the higher-end portions of the RF spectrum(e.g., on the high end of the aforementioned exemplary 1.6 GHz band) ascompared to those more distant, the latter requiring greater ordisproportionate amplification. As such, the present disclosurecontemplates use of selective mapping of frequency spectrum usage as afunction of total cable medium run length or similar.

Another factor of transmission medium performance is the velocity factor(VF), also known as wave propagation speed or velocity of propagation(VoP), defined as the ratio of the speed at which a wavefront (of anelectromagnetic or radio frequency signal, a light pulse in an opticalfiber or a change of the electrical voltage on a copper wire) propagatesover the transmission medium, to the speed of light (c, approximately3E08 m/s) in a vacuum. For optical signals, the velocity factor is thereciprocal of the refractive index. The speed of radio frequency signalsin a vacuum is the speed of light, and so the velocity factor of a radiowave in a vacuum is 1, or 100%. In electrical cables, the velocityfactor mainly depends on the material used for insulating thecurrent-carrying conductor(s). Velocity factor is an importantcharacteristic of communication media such as coaxial, CAT-5/6 cables,and optical fiber. Data cable and fiber typically has a VF betweenroughly 0.40 and 0.8 (40% to 80% of the speed of light in a vacuum).

Achievable round-trip latencies in LTE (UL/DL) are on the order of 2 ms(for “fast” UL access, which eliminates need for scheduling requests andindividual scheduling grants, thereby minimizing latency, and shorterTTI, per Release 15), while those for 5G NR are one the order of 1 ms orless, depending on transmission time interval frequency (e.g., 60 kHz).

Notably, a significant portion of 4G/4.5G transport latency relates tonetwork core and transport (i.e., non-edge) portions of the supportinginfrastructure.

Hence, assuming a nominal 0.7 VF and a one (1) ms roundtrip latencyrequirement, putative service distances on the order of 100 km arepossible, assuming no other processing or transport latency:

0.5E-03s(assume symmetric US/DS)×(0.7×3E08 m/s)×1 km/1000 m=1.05E02 km

As discussed in greater detail below with respect to FIGS. 8a and 8b ,the exemplary embodiments of the architecture 500 may utilize IF(Intermediate Frequencies) to reduce attenuation that exists at thehigher frequencies on the bearer medium (i.e., coaxial cable).

Network Node and DUe Apparatus—

FIGS. 8 and 8 a illustrate exemplary configurations of a network radiofrequency node apparatus 509 according to the present disclosure. Asreferenced above, these nodes 509 can take any number of form factors,including (i) co-located with other MSO equipment, such as in aphysically secured space of the MSO, (ii) “strand” or pole mounted,(iii) surface mounted, and (iv) buried, so as to inter alia, facilitatemost efficient integration with the extant HFC (and optical)infrastructure, as well as other 4G/5G components such as the CUe 504.

As shown, in FIG. 8, the exemplary node 509 in one embodiment generallyincludes an optical interface 802 to the HFC network DWDM system (seeFIG. 2), as well as a “Southbound” RF interface 804 to the HFCdistribution network (i.e., coax). The optical interface 802communicates with an SFP connector cage 806 for receiving the DWDMsignals via the interposed optical fiber. A 5G NR DUe 506 is alsoincluded to provide 5G DU functionality as previously described, basedon the selected option split. The MIMO/radio unit (RU) stages 808operate at baseband, prior to upconversion of the transmitted waveformsby the IF (intermediate frequency) stages 810 as shown. As discussedbelow, multiple parallel stages are used in the exemplary embodiment tocapitalize on the multiple parallel data streams afforded by the MIMOtechnology within the 3GPP technology. A tilt stage 812 is also utilizedprior to the diplexer stage 814 and impedance matching stage 816.Specifically, in one implementation, this “tilt” stage is used tocompensate for non-linearity across different frequencies carried by themedium (e.g., coaxial cable). For instance, higher frequencies may havea higher loss per unit distance when travelling on the medium ascompared to lower frequencies travelling the same distance on the samemedium. When a high bandwidth signal (e.g. 50-1650 MHz) is transmittedon a coax line, its loss across the entire frequency bandwidth will notbe linear, and may include shape artifacts such as a slope (or “tilt”),and/or bends or “knees” in the attenuation curve (e.g., akin to alow-pass filter). Such non-linear losses may be compensated for toachieve optimal performance on the medium, by the use of one or moretilt compensation apparatus 812 on the RF stage of the node device.

A synchronization signal generator 818 is also used in some embodimentsas discussed in greater detail below with respect to FIG. 8 a.

In the exemplary implementation of FIG. 8a , both 4G and 5G gNB DUe 807,506 are also included to support the RF chains for 4G and 5Gcommunication respectively. As described in greater detail below, the 5Gportion of the spectrum is divided into two bands (upper and lower),while the 4G portion is divided into upper and lower bands within adifferent frequency range. In the exemplary implementation, OFDMmodulation is applied to generate a plurality of carriers in the timedomain. See, e.g., co-owned and co-pending U.S. Pat. No. 9,185,341issued Nov. 10, 2015 and entitled “Digital domain content processing anddistribution apparatus and methods,” and 9,300,445 issued Mar. 29, 2016also entitled “Digital domain content processing and distributionapparatus and methods,” each incorporated herein by reference in theirentirety, for inter alia, exemplary reprogrammable OFDM-based spectrumgeneration apparatus useful with various embodiments of the node 509described herein.

In the exemplary embodiment, the 5G and LTE OFDM carriers produced bythe node 509 utilize 1650 MHz of the available HFC bearer bandwidth, andthis bandwidth is partitioned into two or more sub-bands depending one.g., operational conditions, ratio of “N+0” subscribers served versus“N+i” subscribers served, and other parameters. In one variant, eachnode utilizes RF power from its upstream nodes to derive electricalpower, and further propagate the RF signal (whether at the same ofdifferent frequency) to downstream nodes and devices including thewideband amplifiers.

While the present embodiments are described primarily in the context ofan OFDM-based PHY (e.g., one using IFFT and FFT processes with multiplecarriers in the time domain) along with TDD (time division duplex)temporal multiplexing, it will be appreciated that other PHY/multipleaccess schemes may be utilized consistent with the various aspects ofthe present disclosure, including for example and without limitation FDD(frequency division duplexing), direct sequence or other spreadspectrum, and FDMA (e.g., SC-FDMA or NB FDMA).

As previously noted, to achieve high throughput using a single receiverchipset in the consumer premises equipment (CPEe) 513 and 3GPP 5G NRwaveforms over a single coaxial feeder, such as the coaxial cable thatMSOs bring to their subscriber's premises or the single coaxial cablethat is installed for lower-cost single input single output (SISO)distributed antenna systems (DAS), the total carrier bandwidth that canbe aggregated by the prior art chipset is limited to a value, e.g. 800MHz, which is insufficient for reaching high throughputs such as 10Gbit/s using one data stream alone given the spectral efficienciessupported by the 3GPP 5G NR standard.

Since the 3GPP 5G NR standard supports the transmission of multipleindependent parallel data streams as part of a multiple input multipleoutput (MIMO) channel for the same RF bandwidth to leverage the spatialdiversity that wireless channels afford when multiple antenna elementsare used, the very first generation of 3GPP 5G chipsets will supportsuch parallel MIMO data streams. However, attempts to transmit theseparallel streams over a single cable would generally becounterproductive, as all the streams would occupy the same RF bandwidthand would interfere with each other for lack of spatial diversitybetween them.

Accordingly, the various embodiments of the apparatus disclosed herein(FIGS. 8 and 8 a) leverage the parallel MIMO data streams supported by3GPP 5G NR, which are shifted in frequency in the transceiver node 509before being injected into the single coaxial feeder so that frequencydiversity (instead of spatial diversity; spatial diversity may beutilized at the CPEe and/or supplemental pole-mounted radio access node506 a if desired) is leveraged to achieve the maximum total carrierbandwidth that 3GPP 5G NR chipsets will support with parallel datastreams.

FIG. 8b shows a comparison of prior art LTE/LTE-A frequency bands andassociated guard bands over a typical 100 MHz portion of the allocatedfrequency spectrum (top), as well as a comparable 5G NR frequency bandallocation (bottom). As shown, 5G NR uses a wideband approach, with itsmaximum bandwidth being on the order of 98 MHz. Such use of the wideband5G carrier is more efficient than multicarrier LTE/LTE-A. It provides anumber of benefits, including faster load balancing, less common channeloverhead, and reduced guard bands between carriers (LTE uses for example10% allocated to its guard bands).

In the exemplary embodiment, the 5G and LTE OFDM carriers produced bythe node 509 utilize 1650 MHz of the available HFC bearer bandwidth, andthis bandwidth is partitioned into two or more sub-bands depending one.g., operational conditions, ratio of “N+0” subscribers served versus“N+i” subscribers served, and other parameters. See discussion of FIG.8c below. In one variant, each node utilizes RF power from its upstreamnodes to derive electrical power, and further propagate the RF signal(whether at the same of different frequency) to downstream nodes anddevices including the wideband amplifiers.

While the present embodiments are described primarily in the context ofan OFDM-based PHY (e.g., one using IFFT and FFT processes with multiplecarriers in the time domain) along with TDD (time division duplex)temporal multiplexing, it will be appreciated that other PHY/multipleaccess schemes may be utilized consistent with the various aspects ofthe present disclosure, including for example and without limitation FDD(frequency division duplexing), direct sequence or other spreadspectrum, and FDMA (e.g., SC-FDMA or NB FDMA).

As previously noted, to achieve high throughput using a single receiverchipset in the consumer premises equipment (CPEe) 513 and 3GPP 5G NRwaveforms over a single coaxial feeder, such as the coaxial cable thatMSOs bring to their subscriber's premises or the single coaxial cablethat is installed for lower-cost single input single output (SISO)distributed antenna systems (DAS), the total carrier bandwidth that canbe aggregated by the prior art chipset is limited to a value, e.g. 800MHz, which is insufficient for reaching high throughputs such as 10Gbit/s using one data stream alone given the spectral efficienciessupported by the 3GPP 5G NR standard.

Since the 3GPP 5G NR standard supports the transmission of multipleindependent parallel data streams as part of a multiple input multipleoutput (MIMO) channel for the same RF bandwidth to leverage the spatialdiversity that wireless channels afford when multiple antenna elementsare used, the very first generation of 3GPP 5G chipsets will supportsuch parallel MIMO data streams. However, attempts to transmit theseparallel streams over a single cable would generally becounterproductive, as all the streams would occupy the same RF bandwidthand would interfere with each other for lack of spatial diversitybetween them.

Accordingly, the various embodiments of the apparatus disclosed herein(FIGS. 8 and 8 a) leverage the parallel MIMO data streams supported by3GPP 5G NR, which are shifted in frequency in the transceiver node 509before being injected into the single coaxial feeder so that frequencydiversity (instead of spatial diversity; spatial diversity may beutilized at the CPEe and/or supplemental pole-mounted radio access node506 a if desired) is leveraged to achieve the maximum total carrierbandwidth that 3GPP 5G NR chipsets will support with parallel datastreams. Conceptually, a transparent “pipe” that delivers MIMO streamswhich converge at the CPEe is created. Based on channel quality feedbackfrom the CPEe back to the node (e.g., DUe 506 or node 509), the contentsof the MIMO streams are mapped to different frequency resources, e.g.with a frequency selective scheduler, and the appropriate modulation andcoding scheme (MCS) is selected by the transmission node for thecontents. The aforementioned “pipe” disclosed herein acts in effect as ablack box which internally reroutes different antenna ports to differentfrequency bands on the cable bearer medium.

FIG. 8b shows a comparison of prior art LTE/LTE-A frequency bands andassociated guard bands over a typical 100 MHz portion of the allocatedfrequency spectrum (top), as well as a comparable 5G NR frequency bandallocation (bottom). As shown, 5G NR uses a wideband approach, with itsmaximum bandwidth being on the order of 98 MHz. Such use of the wideband5G carrier is more efficient than multicarrier LTE/LTE-A. It provides anumber of benefits, including faster load balancing, less common channeloverhead, and reduced guard bands between carriers (LTE uses for example10% allocated to its guard bands).

Accordingly, in one variant of the present disclosure (FIG. 8c ), thenode 509 is configured to offset the aforementioned individual parallelMIMO data streams in the frequency spectrum using a plurality of 5G NRwidebands 832 (here, TDD carriers) distributed between lower and upperfrequency limits 852, 854, each wideband having a center frequency andassociated guardband (not shown) to the next adjacent widebandcarrier(s) 832. In one implementation, the 5G NR values of maximumbandwidth and guardband are used; however, it will be appreciated thatthe various aspects of the present disclosure are in no way so limited,such values being merely exemplary. In the illustrated embodiments ofFIG. 8c , N bands or TTD carriers 832 are spread across of the availablespectrum, the latter which may in one example be 1.6 GHz as discussedpreviously herein, although other values are contemplated (including tofrequencies well above 1.6 GHz, depending on the underlying cable mediumlosses and necessary transmission distances involved). As shown,depending on the available bandwidth and the bandwidth consumed by eachTDD carrier 832, more or less of such carriers can be used (three shownon the left portion of the diagram, out to “n” total carriers. Notably,while a number of nominal 98 MHz NR carriers may be used, theembodiments of FIG. 8c also contemplate (i) much wider carriers(depending on the number of layers 837, 838 used, as shown in the bottomportion of FIG. 8c ), and (ii) use of carrier aggregation or CAmechanisms to utilize two or more widebands together effectively as acommon carrier.

As further shown in the top portion 830 of FIG. 8c , a lower band 834 isconfigured for FDD use; specifically, in this implementation, a downlinksynchronization channel 833 (discussed elsewhere herein) is created atthe lower portion of the band 834, and one or more LTE FDD bands 842 arecreated (such as for UL and DL channels as described below with respectto the bottom portion of FIG. 8c ). The total bandwidth of the FDD band834 is small in comparison to the remainder of the spectrum (i.e.,between the lower and upper limits 852, 854), the latter used to carry,inter alia, the 5G NR traffic.

In the exemplary implementation 840 (FIG. 8c , bottom portion) of thegeneralized model 830 (FIG. 8c , top portion), the individual 5G TDDcarriers 832 each include multiple “layers” 837, 838, which in theexemplary configuration correspond to MIMO ports and which can beutilized for various functions. As shown, a common UL/DL layer 837 isassociated with each or the larger carriers 832 (to maintain an uplinkand downlink channel), as are a number (L) of additional UL or DL layers838 (e.g., which can be selectively allocated to UL or DL, the latterbeing the predominant choice due to service asymmetry on the networkwhere DL consumes much more bandwidth than UL). In one variant, eachlayer is 98 MHz wide to correspond to a single NR wideband, althoughthis value is merely exemplary.

Within the LTE FDD band 842, two LTE carriers for UL and DL 835, 836 areused, and a separate DL synchronization channel 833 is used at the lowerend of the spectrum. As will be appreciated, various otherconfigurations of the lower portion of the cable spectrum frequency planmay be used consistent with the present disclosure. In one variant, thelower spectrum portion 842 (FIG. 8c ) is allocated to a 3GPP 4G LTE MIMOcarrier with two parallel streams 835, 836 of about 20 MHz bandwidth fora total of about 40 MHz (including guardbands). This is performed since3GPP Release 15 only supports 5G NR in Non-Standalone (NSA) mode,whereby it must operate in tandem with a 4G/4.5 LTE carrier.

As an aside, 5G NR supports adaptive TDD duty cycles, whereby theproportion of time allocated for downstream and upstream transmissionscan be adapted to the net demand for traffic from the total set oftransmitting network elements, viz. the node and all the CPEe 513sharing the coaxial bus with the node. 4G LTE does not support suchadaptive duty cycles. To prevent receiver blocking in the likelyscenario that the 5G and 4G duty cycles differ, high-rejection filtercombiners 814 (FIG. 8a ) are used in all active network elements, viz.transceiver nodes, inline amplifiers and CPEe 513 for the 4G and 5Gcarriers to not interfere with each other or cause receiver blocking. Inthe exemplary diplexer of FIG. 8a , both 4G and 5G are addressed via ahigh-rejection filter to allow for different duty cycles.

As noted above, another minor portion 833 of the lower spectrum on thecoaxial cable (e.g., <5 MHz) employs one-way communication in thedownstream for the transmission of two digital synchronization channels,one for 5G and one for 4G, which are I-Q multiplexed onto one QPSKanalog synchronization channel within the aforementioned “minor portion”833 from the signal generator 818 of the transceiver node 409 to themultiple inline amplifiers and CPEe 513 that may be sharing the coaxialbus. These synchronization channels aid coherent reception of the PRBs,specifically, the synchronization signal is used to achieve frequencysynchronization of oscillators in all active components downstream fromthe node such as line-extender amplifiers and CPEe's. The oscillatorsfor the 4G and 5G technologies may be independent. If the carrier usesFDD, such as on the 4G LTE channels, frequency synchronization issufficient. If the carrier uses TDD as in the 5G NR portions of FIG. 8c, then phase synchronization is needed as well for downstream componentsto identify the transmission mode—downlink or uplink and the duty cyclebetween the two and the synchronization signal conveys this information.Since lower frequencies attenuate less on the cable, the synchronizationchannel is in one implementation transmitted over a lower portion of thespectrum on the cable (FIG. 8c ) so that it reaches every downstreamnetwork element and CPEe. In one variant, an analog signal is modulatedwith two bits, where one bit switches according to the duty cycle forthe 4G signal, and the other bit switches according to the duty cycle ofthe 5G signal, although other approaches may be utilized.

It will also be recognized that: (i) the width of each 5G TDD widebandcarrier 832 may be statically or dynamically modified based on e.g.,operational requirements such as demand (e.g., network or bandwidthrequirements of any dedicated bearer created for enhanced-QoE voiceservices), and (ii) the number of wideband carriers 832 used (and infact the number of layers utilized within each wideband carrier 832) canbe similarly statically or dynamically modified. It will also beappreciated that two or more different values of bandwidth may be usedin association with different ones of the plurality of widebands, aswell as being aggregated as previously described.

The values of f_(lower) 852 and f_(upper) 854 may also be varieddepending on operational parameters and/or other considerations, such asRF signal attenuation as a function of frequency as discussed in detailpreviously herein. For example, since higher frequencies attenuate muchmore over the coaxial transmission media than lower frequencies, in onevariant the Intermediate Frequencies (IF) are transmitted over themedia, and block-conversion to RF carrier frequency is employedsubsequently in the consumer premises equipment (CPEe) 513 for 3GPPband-compliant interoperability with the 3GPP 5G NR chipset in the CPEe.In this fashion, attenuation that would otherwise be experienced byconversion earlier in the topology is advantageously avoided. Similarly,very short runs of cable (e.g., a “last mile” between a fiber deliverynode and a given premises, or from a distribution node to varioussubscriber CPEe within a multi-dwelling unit (MDU) such as an apartmentor condominium building, hospital, or enterprise or school campus can bemapped out into much higher frequencies since their overall propagationdistance over the cable is comparatively small.

In another variant, active or dynamic Tx/Rx port formation specified inthe 5G NR standards is utilized, yet the formed beams therein aresubstituted with frequency bandwidth assignments as discussed above(i.e., total bandwidth, f_(lower) 852 and f_(upper) 854 values, and TDDcarrier bandwidth values).

The foregoing aspects of FIG. 8c also highlight the fact that, whilesome exemplary configurations described herein utilize two (2) MIMOports or streams as baseline of sorts for frequency diversity on thecable medium (i.e., in order to reduce the frequency-based filteringcomplexity in the CPEe 513), a much greater level of complexity infrequency planning can be utilized consistent with the presentdisclosure, including use of more MIMO layers and different bandwidthsper TDD carrier 832. Specifically, exemplary embodiments herein map thedifferent antenna ports to different frequency bands on the cable, withdifferent frequency bands experiencing different levels of propagationloss, phase delay, environmental interference and self-interference.Hence, independent channels with frequency diversity for signals toreach the CPEe are created. When upconverted to RF frequency at theCPEe, the CPEe in one implementation processes these signals as if theywere received over the air, and will (as shown in block 910 of FIG. 0),upconvert each frequency band on the cable, from 50 to 850 MHz for Port0 and 850 to 1650 MHz for Port 1 in the exemplary embodiment, to thesame RF frequency, thereby realigning them by virtue of a differentfrequency multiplier being applied to each port. Moreover, in theexemplary embodiment. The CPEe provides channel quality information(CQI), rank Indicator (RI) and precoding matrix indicator (PMI) feedbackback to the distribution node 509 consistent with extant 3GPP protocols.If the higher frequencies on the cable medium are not excessivelyattenuated (see FIGS. 7a and 7b ), an RI of 2 (for 2-layer MIMO) will bereported back to the node 509. The node then uses this information tocode independent layers of data to the CPEe. However, depending onpermissible complexity in the CPEe and the physical characteristics ofthe cable relative to topological location of the CPEe, four (4), oreven (8) layers may be utilized in place of the more simple 2-layerapproach above.

In operation, the IF carriers injected by the transceiver node into thecoaxial feeder 804 can be received by multiple CPEe 513 that share thefeeder as a common bus using directional couplers and power dividers ortaps. Point-to-Multipoint (PtMP) downstream transmissions from the node409 to the CPEe 413 can be achieved by, for instance, scheduling payloadfor different CPEe on different 3GPP 5G NR physical resource blocks(PRB) which are separated in frequency.

In the exemplary embodiments of FIG. 8c , the vast majority of bandwidthin the coaxial cable bearer is used in Time Division Duplex (TDD)fashion to switch between downstream (DS) and upstream (US) 5G NRcommunications, depending on the configuration of the particular layers837, 838 used in each TDD carrier 832. Upstream communications from themultiple CPEe 513 to the transceiver node can also/alternatively occursimultaneously over separate PRBs (with frequency separation) ifdesired. The connectivity between the transceiver node 509 and thenorthbound or upstream network element is achieved with a fiber opticlink 802 to the MSO DWDM plant. To minimize the number of fiber channelsrequired to feed the transceiver node 509, and to restrict it to a pairof fiber strands, in one embodiment the 3GPP 5G NR F1 interface(described supra) is realized over the fiber pair to leverage the lowoverhead of the F1 interface. The 3GPP 5G NR Distribution Unit (DUe)functionality is incorporated into the transceiver node 509 aspreviously described, since the F1 interface is defined between theCentral Unit (CU/CUe) and DU/DUe where, in the illustrated embodiment,the CUe and DUe together constitute a 3GPP 5G NR base station or gNB(see FIGS. 5a-5f ).

An Ethernet switch 805 is also provided at the optical interface in theembodiment of FIG. 8a to divide the backhaul into the 4G and 5G datapaths (e.g., the received upstream 4G and 5G signals are respectivelyrouted differently based on the switch 805).

The exemplary node 509 also includes a power converter 819 to adapt forinternal use of quasi-square wave low voltage power supply technologyover HFC used by DOCSIS network elements as of the date of thisdisclosure. The node 509 in one variant is further configured to passthe quasi-square wave low voltage power received on the input port 801through to the HFC output port 804 to other active network elements suchas e.g., amplifiers, which may be installed downstream of the node onthe HFC infrastructure.

It is noted that as compared to some extant solutions, the illustratedembodiment of FIGS. 5 and 8, 8 a, 8 c uses HFC versus twisted pair tofeed the CPEe 513; HFC advantageously provides lower loss and widerbandwidths than twisted pair, which is exploited to provide 5Gthroughputs to farther distances, and to leverage the large existingbase of installed coaxial cable. Moreover, the foregoing architecture inone implementation is configured to serve multiple CPEe 513 usingdirectional couplers and power dividers or taps to attach to a commoncoaxial bus which connects to a single interface at the transceivernode. The aforementioned Ethernet services (necessary to service anexternal Wi-Fi access-point and an integrated Wi-Fi router) are furtheradded in other implementations to provide expanded capability, incontrast to the existing solutions.

CPEe Apparatus—

FIG. 9 illustrates an exemplary configuration of a CPEe apparatus 513according to the present disclosure. As shown, the CPEe 513 generally anRF input interface 916 to the HFC distribution network (i.e., coax dropat the premises). A transmitter/receiver architecture generallysymmetrical to the transmitter/receiver of the node 509 discussedpreviously is used; i.e., impedance matching circuitry, diplexer,synchronization circuit, tilt, etc. are used as part of the CPEe RFfront end. Block converters 911 are used to convert to and from thecoaxial cable domain bands (here, 50-850 and 850-1650 MHz) to thepremises domain, discussed in greater detail below.

The exemplary CPEe 513 also includes a 5G UE process 908 to implement3GPP functionality of the UE within the CPEe, and 3GPP (e.g., 5G/LTE)repeater module 909 which includes one or more antennae elements 910 forindoor/premises coverage within the user RF band(s). As such, the CPEe513 shown can in effect function as a base station for user deviceswithin the premises operating within the user band(s).

A 10 GbE WLAN port 918 is also included, which interfaces between the UEmodule 908 and the (optional) WLAN router 517 with internal 10 GbEswitch 919) to support data interchange with premises WLANinfrastructure such as a Wi-Fi AP.

Also shown in the configuration of FIG. 9 are several external ports912, 914 for external antenna 516 connection (e.g., roof-top antennaelement(s) used for provision of the supplemental data link aspreviously described with respect to FIG. 5), wireless high-bandwidthbackhaul, or other functions.

In the exemplary implementation of FIG. 9a , both 4G and 5G gNB blockconverters 932, 930 are included to support the RF chains for 4G and 5Gcommunication respectively (i.e., for conversion of the IF-band signalsreceived to the relevant RF frequencies of the 4G/5G interfaces andmodems within the CPEe, such as in the 2 GHz band. The block convertersalso enable upstream communication with the distribution node 509 viathe relevant IF bands via the coaxial input 917 as previously described.

Notably, the CPEe 513 applies block-conversion between the IF and RFcarrier frequency for the 4G and 5G carrier separately since they may beon different frequency bands. The CPEe includes in one implementation a5G NR and 4G LTE-capable user equipment (UE) chipset 916. The twotechnologies are supported in this embodiment, since the first releaseof 3GPP 5G NR requires 4G and 5G to operate in tandem as part of thenon-standalone (NSA) configuration.

It is noted that in the exemplary configuration of FIG. 9a (showing thelower frequencies in 4G combined with 5G), a filter combiner is used (incontrast to the more generalized approach of FIG. 9).

It is also noted that the specific implementation of FIG. 9a utilizes“tilt” compensation as previously described on only one of the RF-IFblock converters 930. This is due to the fact that the need for suchcompensation arises, in certain cases such as coaxial cable operated inthe frequency band noted) disproportionately at the higher frequencies(i.e., up to 1650 MHz in this embodiment). It will be appreciatedhowever that depending on the particular application, differentcompensation configurations may be used consistent with the presentdisclosure. For example, in one variant, the upper-band block converters930 may be allocated against more granular frequency bands, and hencetilt/compensation applied only in narrow regions of the utilizedfrequency band (e.g., on one or two of four 5G RF-IF block converters).Similarly, different types of tilt/compensation may be applied to eachblock converter (or a subset thereof) in heterogeneous fashion. Variousdifferent combinations of the foregoing will also be appreciated bythose of ordinary skill given the present disclosure.

Block conversion to the RF frequency makes the signals 3GPPband-compliant and interoperable with the UE chipset in the CPEe 513.The RF carriers are also then amenable for amplification through theincluded repeater 909 for 4G and 5G which can radiate the RF carriers,typically indoors, through detachable external antennas 910 connected tothe CPEe. Mobile devices such as smartphones, tablets with cellularmodems and IoT devices can then serve off of the radiated signal for 4Gand 5G service (see discussion of FIGS. 13a and 13b below).

The UE chipset 916 and the repeater 909 receive separate digital I/Qsynchronization signals, one for 4G and one for 5G, for switchingbetween the downstream and upstream modes of the respective TDDcarriers, since they are likely to have different downstream-to-upstreamratios or duty cycle. These two digital synchronization signals arereceived from an I-Q modulated analog QPSK signal received fromlower-end spectrum on the coaxial cable that feeds the CPEe 513 via theport 917.

In the exemplary implementation of FIG. 9b , both IF-RF block converters952, 950 are included to support the RF chains for 5G communication(i.e., for conversion of the IF-band signals received to the relevant RFfrequencies of the 5G interfaces and modems within the CPEe, such as inthe 2 GHz band, and vice versa). The block converters also enableupstream communication with the distribution node 509 via the relevantIF bands via the coaxial input 917 as previously described.

The CPEe of FIG. 9b includes in one implementation a 5G NR and 4GLTE-capable user equipment (UE) chipset 956. The two technologies maysupported for, inter alia, support of the first release of 3GPP 5G NRrequires 4G and 5G to operate in tandem as part of the non-standalone(NSA) configuration, although a standalone (SA) variant utilizing purely5G NR waveforms is also contemplated.

The specific implementation of FIG. 9b again utilizes “tilt”compensation as previously described both of the RF-IF block converters950, 952. This is due to the fact that the need for such compensationarises, in certain cases such as coaxial cable operated in the frequencyband noted) disproportionately at the higher frequencies (i.e., up to1650 MHz in this embodiment), and hence even the lower Port 0 blockconverter operating up to 850 MHz for this embodiment may require somedegree of tilt compensation. As with the embodiment of FIG. 9a ,depending on the particular application, different compensationconfigurations may be used consistent with the present disclosure.

Block conversion to the RF frequency makes the signals 3GPPband-compliant and interoperable with the UE chipset 956 in the CPEe513. The RF carriers are also then amenable for amplification throughthe included repeater 909 for 5G which can radiate the RF carriers,typically indoors, through detachable external antennas 910 connected tothe CPEe. Mobile devices such as smartphones, tablets with cellularmodems and IoT devices can then serve off of the radiated signal for 5G(and 4G, where so equipped) service (see discussion of FIGS. 13a and 13bbelow).

The UE chipset 956 and the repeater 909 receives digital I/Qsynchronization signals (not shown) for switching between the downstreamand upstream modes of the respective TDD carriers. These digitalsynchronization signals are received from an I-Q modulated analog QPSKsignal received from lower-end spectrum on the coaxial cable that feedsthe CPEe 513 via the port 917.

As noted, in the exemplary implementation, OFDM modulation is applied togenerate a plurality of carriers in the time domain at the distributionnode 509; accordingly, demodulation (via inter alia, FFT) is used in theCPEe to demodulate the IF signals. See, e.g., co-owned and co-pendingU.S. Pat. No. 9,185,341 issued Nov. 10, 2015 and entitled “Digitaldomain content processing and distribution apparatus and methods,” and9,300,445 issued Mar. 29, 2016 also entitled “Digital domain contentprocessing and distribution apparatus and methods,” each incorporatedherein by reference in their entirety, for inter alia, exemplaryreprogrammable OFDM-based receiver/demodulation apparatus useful withvarious embodiments of the CPEe 513 described herein.

Similar to the embodiment of FIG. 9, a 10 Gbe Ethernet port andassociated GbE switch 922 is also provided to support operation of theWLAN router 517 in the devices of FIGS. 9a and 9b , including for LANuse within the served premises.

Further, to boost the broadband capacity beyond the capacity availablethrough the primary coaxial cable link and to add a redundant connectionfor higher reliability (which could be important for small businesses,enterprises, educational institutions, etc.), two additional RFinterfaces on the CPEe of FIGS. 9a and 9b are included for connectingthe CPEe to a 2-port external antenna 516 which is installed outdoors,e.g., on the roof of the small business, multi-dwelling unit (MDU) ormulti-story enterprise. This external antenna can be used to receivesupplemental signals from outdoor radios installed in the vicinity ofthe consumer premises. It will be appreciated that the outdoor radiosmay have a primary purpose of providing coverage for outdoor mobility,but signals from them can also/alternatively be used in a fixed-wirelessmanner to supplement the capacity from the primary coaxial link and toadd redundancy, as described elsewhere herein.

IoTG Apparatus—

FIG. 10a is a functional block diagram illustrating an exemplary generalconfiguration of an IoTG Gateway according to the present disclosure.

As shown in FIG. 10a , the IoTG includes, a plurality of heterogeneousRx/Tx RF front ends, antennae elements, baseband processing modules. Itwill be appreciated that while IEEE Std. 802.15.4, BLE, LoRA NB-IOT,MMTC, etc. interfaces are shown in the figure, literally any combinationof interfaces may be used (so long as they are configured to be mutuallynon-interfering, whether by frequency band, spreading code, MCS used,TDD, or medium access contention resolution mechanisms).

In this and various embodiments, the IOT Gateway includes the functionsof the IoTG server stack and the communication with relevant networkentities such as the CPEe and upstream nodes 509. IOT gateway isconnected to different IOT access front ends. The spectrum used will bethe following for different RF front ends, 900 MHz for LORA, 3.5 GHzradio front end for NB-IOT/CAT-M, mmWave 37 GHz radio front end forMMTC/CMTC and Bluetooth LE. These all get consolidated in the IOTgateway which connects to either 4G/5G access via 10GE internal switch.

The IOT gateway will have an IOT stack where all the data from thedifferent IOT modules will be combined.

As shown in the figure the data will be routed to 4G/5G interface viathe 10GE switch which is being shared between the IOT gateway and 5GCPE.

The network interface(s) generally includes wireline data interfacessuch as IEEE 802.3 Ethernet/GbE/10 GbE (via CAT-5/6 cabling), IEEE-1394,USB, or other, useful for transmitting data communications (such as theIoT “data) upstream for delivery to the CPEe and ultimately to the HFCnetwork (FIG. 5), as well as for transacting data for control or accessof the IoTG from the remote mobile device (see discussion of FIGS. 12and 12 b below). For example, in one embodiment, the interface comprisesa 10 GbE interface between the IoTG and the CPEe via the 10GE switch

It will be appreciated that while shown as separate components, two ormore of the IoTG, 10GE switch and CPEe can be combined into a commondevice, thereby further simplifying the architecture.

FIG. 10b is a functional block diagram illustrating an exemplaryimplementation of a standalone IoTG apparatus 519 according to thepresent disclosure.

As shown in FIG. 10b , the IoTG 519 includes, inter alia, a processorsubsystem with CPU 1032, a memory module 1034, one or more network datainterfaces 1038, and a plurality of heterogeneous Rx/Tx RF front ends1036 a-e, antennae elements 1040 a-b, and MAC baseband processingmodules 1035 a-e for respective ones of the different air interfacessupported by the IoTG 519. It will be appreciated that while IEEE Std.802.15.4, BLE, LoRA, etc. interfaces are shown in the figure, literallyany combination of interfaces may be used (so long as they areconfigured to be mutually non-interfering, whether by frequency band,spreading code, MCS used, TDD, or medium access contention resolutionmechanisms).

The processor subsystem 1032 of the IoTG 519 may include one or more ofa digital signal processor (DSP), microprocessor (e.g., RISC core(s)such as ARM core), field-programmable gate array, or plurality ofprocessing components mounted on one or more substrates (e.g., printedcircuit board). The processor subsystem/CPU 1032 may also comprise aninternal cache memory (e.g., L1/L2/L3 cache). The processor subsystem isin communication with a memory subsystem 1004, the latter includingmemory which may for example comprise SRAM, flash, and/or SDRAMcomponents. The memory subsystem may implement one or more of DMA-typehardware, so as to facilitate data accesses as is well known in the art.The memory subsystem of the exemplary embodiment containscomputer-executable instructions which are executable by the processorsubsystem.

In this and various embodiments, the processor subsystem/CPU 1032 isconfigured to execute at least one computer program stored in programmemory 1034 (e.g., a non-transitory computer readable storage medium),including functions of the IoTG server stack where equipped 1021, and tosupport the IoT sniffer 1020 is used, as well as communication withrelevant network entities such as the CPEe and upstream nodes 509. Interms of the IoT sniffer 1020, see, e.g., co-pending U.S. patentapplication Ser. No. 15/821,218 filed Nov. 22, 2017 and entitled“APPARATUS AND METHODS FOR PREMISES DEVICE EXISTENCE AND CAPABILITYDETERMINATION,” which is incorporated herein by reference in itsentirety. As disclosed therein, the IoT sniffer function and moduleleverages the ability to passively canvass or assess a given premises asto its IoT profile, including both transparent and proxy-managedinstallations. Data obtained via this canvassing can be utilized bye.g., a network operator or service provider for any number of differentfunctions, including (i) populating on-screen displays such ascloud-based EPGs or device setup UIs with data relating to all such IoTdevices within the premises; and (ii) one-stop management of variousaspects of the IoT devices (e.g., naming, interconnectivity functions,reporting, etc.). In one embodiment thereof, the passive canvassing ofthe premises is conducted by a software-defined radio (SDR) deviceincorporated into another MSO (host) device at the premises (here, theIoTG 519 and/or CPEe 513 depending on configuration). The SDR iscontrolled by logic operative to run on the host device, enabling theSDR to scan the RF environment within the premises in particularfrequency bands typically associated with IoT devices and protocols,including those of the IoTG air interfaces. In one variant, the SDR andlogic are configured to acquire and decode one or more broadcastchannels of the IoT device(s) to obtain yet additional informationregarding the particular device. The sniffer (if used) may also make useof the extant IoT air interfaces of the IoTG 519, such as for IoT devicecanvassing and detection, thereby avoiding any requirement or use ofduplicative air interfaces.

Advantageously, by having the IoT sniffer module 1020 co-located withthe IoTG 519, the typically centralized location of the IoTG can beleveraged for the characteristically shorter range of the IoT (PAN)interfaces. Moreover, even if the PAN interfaces use the same 2.4 GHzband as the WLAN interface 517 of the router, mutual interference to theWLAN modem and vice versa is mitigated by, for instance the reducedsignal strength, different sub-band allocations, and CSMA-CD mechanismsof the exemplary 802.15.4 MAC/PHY of the typical IoT device. Notably,IEEE Std. 802.11g/n implementations use a 20 MHz channel width, with16.25 MHz allocated to sub-carriers for the OFDM interface.Specifically, channels at 2412, 2437, and 2462 MHz are supported.Similarly, 40 MHz channels with 33.75 allocated to OFDM subcarriers maybe used in certain modes of 802.11n for enhanced data throughput; e.g.,centered at 2422 MHz.

Various other functions in support of the individual air interfacemodems are also performed by the device, including baseband management(e.g., transmit and receive functions via the baseband processor 1035and associated Tx and Rx chains of the RF front end 1036 and their MIMOor spatially diverse antenna elements 1040 a, 1040 b).

As shown in FIG. 10b , the network interface(s) 1038 generally includeswireline data interfaces such as IEEE 802.3 Ethernet/GbE/10 GbE (viaCAT-5/6 cabling), IEEE-1394, USB, or other, useful for transmitting datacommunications (such as the IoT “data) upstream for delivery to the CPEe513 and ultimately to the HFC network (FIG. 5), as well as fortransacting data for control or access of the IoTG from the remotemobile device (see discussion of FIGS. 12 and 12 b below). For example,in one embodiment, the interface comprises a 10 GbE interface betweenthe IoTG and the CPEe when configured as stand-alone devices.

It will be appreciated that while shown as separate components, two ormore of the IoTG 519, WLAN router 517 and CPEe 513 can be combined intoa common device, thereby further simplifying the architecture.

IoTG-Enabled Mobile Device—

FIG. 11 is a functional block diagram illustrating an exemplary generalconfiguration of a mobile client device 507 with IoTG control andinterface capability, according to the present disclosure. As shown inFIG. 11, the mobile client device 507 (e.g., the user mobile deviceshown in FIG. 5) includes, inter alia, a processor subsystem with CPU1152, a memory module 1154, one or more network interfaces 1158,graphics co-processor (GPU) 1160, a DRM manager 1162, mass storagedevice 1166, DSP 1168, user interface (UI) 1164 and an RF basebandprocessing module 1116. The client device 507 also includes a PANinterface (e.g., Bluetooth or BLE) 1170, WLAN (802.11) interface 1172,and cellular data/voice interface(s) 1174.

In one exemplary embodiment, the processor subsystem/CPU 1152 mayinclude one or more of a digital signal processor (DSP), microprocessor(e.g., RISC core(s) such as ARM core), field-programmable gate array, orplurality of processing components mounted on one or more substrates(e.g., printed circuit board). The processor subsystem/CPU 1152 may alsocomprise an internal cache memory (e.g., L1/L2/L3 cache). The processorsubsystem is in communication with a memory subsystem 654, the latterincluding memory which may for example comprise SRAM, flash, and/orSDRAM components. The memory subsystem may implement one or more ofDMA-type hardware, so as to facilitate data accesses as is well known inthe art. The memory subsystem of the exemplary embodiment containscomputer-executable instructions which are executable by the processorsubsystem.

In this and various embodiments, the processor subsystem/CPU 1152 isconfigured to execute at least one computer program stored in programmemory 1154 (e.g., a non-transitory computer readable storage medium). AGPU 1160 and DRM module 1160 are also in data communication with theprocessor subsystem 1152, and collectively the foregoing componentsinclude a plurality of computer programs/firmware configured to performvarious functions such as conditional access/digital rights management,decryption, content decode and rendering, as well as communication withrelevant network entities such as the IoTG server stack 1021 or themanaged network proxy or application server (where used; see FIG. 12a ).Various other functions useful for and typical in consumer electronicsincluding user interface via the UI 1164 (e.g., capacitive touch-screenwith soft function key generation) and speech recognition via the DSP1168 are provided in the exemplary device.

In operation, the IoTG client application 1121 executes on the CPU 1152to enable the user to access, visualize, and control as applicable thevarious IoT devices 565 a-c within the controlled premises. The clientapplication or “app” logically communicates with the IoTG serverfunctionality (wherever disposed) so as to enable such functions by theuser, including when mobile and away from the premises.

FIG. 12a is a functional block diagram illustrating a first exemplarynetwork architecture 1200 for IoTG connectivity with the mobile deviceof FIG. 11. Specifically, as shown, the architecture includes theaforementioned mobile device 507 (FIG. 11) which interfaces with a 5GgNB, WLAN AP, or other such access point via the relevant air interface(5G NR, IEEE Std. 802.11, etc.) for its PHY. In this embodiment, sincethe gNB is 5G NR compliant, 5G core functions and protocols may extendall the way to the mobile device 507, including use of 5G signaling,slicing, and other such functions afforded by Release 16 and beyond.

An MSO IoTG application server process 1220 is also in datacommunication with the 5GC (and hence the mobile device application 1121via the gNB); the application server also is in logical communicationwith the IoTG process 1021 operative to run on the IoTG 519 at thecontrolled premises (via the 5G node 509, CPEe 513 and IoTG 519 asshown).

FIG. 12b is a functional block diagram illustrating a second exemplarynetwork architecture 1240 for IoTG connectivity with the mobile deviceof FIG. 11. In this approach, the mobile device 507 again communicateswirelessly with an access point, but here the exemplary access point isa 4G/4.5G eNB, which is served and communicative with the legacy EPC 333(as in some NSA implementations). The 5G gNB is in user and controlplane data communication with and is served by the EPC. The IoTG 519 inthis embodiment is also configured to provide the functionality of theapplication server 1220 of FIG. 12a ; the EPC or MSO maintains nodedicated IoTG server, but rather each user maintains logicalconnectivity with their respective IoTG 519 for control or access to theIoTG functions and connected devices 556 a-c.

CPE/IoTG Control and IoT Data Services Using an Embedded Channel—

As previously described, at least the initial set of 3GPP 5G standardsis based on an operating mode known as “non-standalone” or NSA. Asdiscussed, in NSA mode the connection is anchored in LTE, while 5G NRcarriers are used to boost data-rates and reduce latency.

Also, some initial NR equipment implementations may only support aconnection to an LTE core network, since the 5G core networkstandardization may still be in progress. In such cases, for a 5G NR tooperate, an LTE carrier must exist and be used for at least the systemcontrol channels (e.g. BCCH, PCCH, RACH, etc.). As technology migrationfrom LTE/LTE-A toward 5G NR has evolved, other NSA configurations(including those involving a 5GC such as that shown in FIG. 5d herein)are supported. Advantageously, the various principles of the presentdisclosure are equally adaptable to both 5GC-based and EPC-basedimplementations.

The first generation of 5G capable end device chipsets will support anLTE anchor channel, since this will be the defacto mode of operation forsome time. Hence, in one variant, the CPEe 513 for an evolved HFCnetwork using 3GPP 5G waveforms is based on available device chipsetswhich support LTE anchor channels.

It is desired that the 5G NR portion of the network architecture 500 ofFIG. 5 be tasked with delivering the data between the end user devices(e.g., UEs) and the core network (and on to the outside world). The LTEanchor channel is needed for system control information for allconnected devices in such cases where the EPC core is utilized. Aremaining portion of the anchor channel bandwidth can be used forcommand and control data, such as for the CPEe endpoints. This approachadvantageously isolates the CPE control traffic from the end usertraffic, and provides a means for issuing command and control (C&C) tothe CPEe 513 along with other useful machine-to-machine (M2M)information for the service provider or a proxy. Moreover, the inventiveCPEe 513 and/or IoTG 519 of FIG. 5 appear to the LTE (core) system asvalid end user devices with subscription credentials (SIM, eSIM, etc.).A portion of the LTE traffic bandwidth is taken up in the C&C trafficbetween the CPEe and the MSO's OAM system. The remainder of the LTEtraffic bandwidth may be used for other purposes, including additionalbandwidth to the served UE(s), IoT device support, and/or yet othertypes of applications.

FIGS. 13a and 13b illustrate two exemplary NSA (non-standalone)architectures 1300, 1350 respectively, according to the presentdisclosure. The system control channels (dashed lines) required for theNSA LTE anchor channel are shown, as well as the command and controldata embedded within the LTE channel (solid lines), which convey commandand control information between the network OSS and the CPEe(s) 513.Also shown are 5G NR high-speed data (HSD) channels (thick lines)between the core network (in this instance, an EP Core 333) and the enduser devices (e.g., 3GPP UE such as a laptop, smartphone, although theCPEe may also function as an end user device is certain configurations).The 5G NR gNBs 501 operate to provide, inter alia, connectivity betweenthe CPEe 513 and the core via the architecture of FIG. 5 discussed supra(e.g., via the HFC infrastructure). The data connection between the CPEeand the UE can be Ethernet (e.g. Cat-6 UTP) or Wi-Fi, for example,although other wired and wireless interfaces may be substituteddepending on the particular application.

The primary difference between the architectures 1300, 1350 shown isthat in FIG. 13a , the gNB 501 utilizes the eNB 317 to support itsuser-plane data, whereas in FIG. 13b , the gNB 501 is in directcommunication with the EPC for such purposes (see discussion of FIG. 6esupra). In each case, however, the command and control data 1310terminate at the UE 507 via the CPEe 513.

Conversely, in a 5G network architecture operating in “stand-alone” mode(see e.g., FIGS. 6a-6c ), a similar method may be employed; however,instead of an LTE channel being used as an anchor for command andcontrol data, a “pure” 5G NR solution can be employed (i.e., withoutpreservation of the anchor). The CPEe 513 in such case appear as 5G enddevices (UE) with subscription credentials. The CPEe command and controltraffic is a portion of the overall traffic bandwidth, and terminate atthe CPEe 513.

Referring to the architectures 1400, 1450 of FIGS. 14a and 14b ,respectively, the NSA-mandated LTE anchor channel is required for systemcontrol information, but a large amount of bandwidth for this functionis neither necessary nor desirable, as it would remove bandwidth thatcould otherwise be used by the 5G NR portion of the spectrum.Accordingly, in this approach, a narrow bandwidth channel is used thatis compatible with 3GPP IoT standards (i.e. eMTC, NB-IoT); a portion ofthe LTE anchor channel may be used for IoT transmissions with the CPEe513 serving as the endpoint for the IoT connections (rather than the UEserving as the LTE endpoint as in FIG. 13a-13b ).

For example, eMTC/NB-IoT may occupy a 1 MHz edge band, while 5G userscan use the remaining bandwidth. In some aspects, two edge 1 MHz bandsmay be used for eMTC/NB-IoT within an 80 MHz system, and 5G users mayuse the remaining center 78 MHz band. In some cases, 5G signals such ascell-specific reference signal (CRS) and channel state informationreference signal (CSI-RS) may occupy only the remaining bandwidth (e.g.,the center band of 78 MHz). In some aspects, 5G signals such as CRS andCSI-RS may occupy the whole bandwidth, and puncture eMTC/NB-IoT users.

For 5G systems, when NB-IoT or eMTC are present, the eNB 317 canindicate different control regions via master information block (MIB) orsystem information block (SIB) signaling. The different control regionsmay avoid collision with the NB-IoT/eMTC bandwidth. This may reduce thepuncturing of NB-IoT/eMTC by the 5G systems. Once the control region isorthogonal to the NB-IoT/eMTC, the data region orthogonality can bemaintained by scheduling.

In one embodiment, one or more coverage extension (CE) or coverageenhancement (CE) configurations are utilized in the random access withrespective specific settings to serve UEs 507 and/or IoT devices 556 a-cin different coverage conditions that have different ranges of pathloss. That is, when UEs 507 and/or IoT devices 556 a-c are located inthe CE regions, they can have difficulty receiving the downlink channel,or the base station (e.g., eNB 317) can have difficulty receiving theuplink channel. Accordingly, the eNB selects the configuration of theradio resources; and the Modulation and Coding Scheme (MCS) andrepetitions depend on UE's coverage. In one variant, a CE configurationincludes performing bundle transmissions (i.e., repeated transmissionsof uplink/downlink channels on a plurality of subframes). The specificsettings of the CE configurations vary, and can include, e.g., how manyrepeated transmissions are allowed, how many subframes are used, etc.

NB-IoT defines three operation modes to provide deployment flexibility:

(i) Stand-alone (utilizing, for example, one or more GSM carriers);

(ii) Guard-band (utilizing the unused resource blocks within an LTEcarrier's guardband); and

(iii) In-band (utilizing resource blocks within an LTE carrier).

In certain aspects of the present disclosure, NB-IoT/eMTC can bedeployed in the guardband of 5G systems. In one variant, the signalingfor NB-IoT and eMTC can be extended to allow wider bandwidth support,e.g. indicating narrowband location within 80 MHz instead of 20 MHz. Incertain aspects, NB-IoT/eMTC can be deployed at the edge of the narrowband.

NB-IoT provides the following physical signals and channels in thedownlink:

(i) Narrowband Primary Synchronization Signal (NPSS);

(ii) Narrowband Secondary Synchronization Signal (NSSS);

(iii) Narrowband Physical Broadcast Channel (NPBCH);

(iv) Narrowband Reference Signal (NRS);

(v) Narrowband Physical Downlink Control Channel (NPDCCH); and

(vi) Narrowband Physical Downlink Shared Channel (NPDSCH).

Unlike LTE, these NB-IoT physical channels and signals are primarilymultiplexed in time.

NPSS and NSSS are used by an NB-IoT UE to perform cell search, whichincludes time and frequency synchronization, and cell identitydetection. NPBCH carries the master information block (MIB).

NPDCCH carries scheduling information for both downlink and uplink datachannels. It further carries the HARQ acknowledgement information forthe uplink data channel as well as paging indication and random accessresponse (RAR) scheduling information.

NPDSCH carries data from the higher layers as well as paging message,system information, and the RAR message.

NRS is used to provide phase reference for the demodulation of thedownlink channels.

NB-IoT includes the following channels in the uplink.

(i) Narrowband Physical Random Access Channel (NPRACH); and

(ii) Narrowband Physical Uplink Shared Channel (NPUSCH).

NB-IoT is designed to allow a UE to learn the deployment mode(stand-alone, in-band, or guard-band) as well as the cell identity (bothNB-IoT and LTE) through initial acquisition. In one variant, thedeployment scenario, stand-alone, in-band, or guard-band, however istransparent to a client device (e.g., UE 507, CPEe 513 or IoTG 519) whenit is first turned on and searches for an NB-IoT carrier. Then theclient device can determine which resource elements are used by LTE.

For the stand-alone and guard-band deployments, no LTE resource needs tobe protected, thus NPDCCH, NPDSCH or NRS can utilize all the resourceelements in one PRB pair (defined as 12 subcarriers over one subframe).However, for in-band deployment (see discussion of FIGS. 17-21 of thepresent disclosure), NPDCCH, NPDSCH or NRS cannot be mapped to theresource elements taken by the LTE Cell-Specific Reference Symbols (CRS)and LTE Physical Downlink Control Channel (PDCCH).

When the 5G stand-alone (SA) operating mode becomes available, operationof IoT channels without the LTE components will be supported, and hencethe anchor channel can be obviated, and command and control of the CPEe(and other such applications) over the IoT channel alone maintained.

Referring to the architectures 1500, 1550 of FIGS. 15a and 15b , anarrow bandwidth channel is employed within the system that iscompatible with 3GPP IoT standards (i.e. eMTC, NB-IoT), and this channelcan be used for inter alia, IoT transmissions to standard IoT enddevices 556. The HFC coax RF distribution network of the MSO (e.g., thatof FIG. 5) serves as a “distributed antenna system” or DAS of sorts forthe IoT channel, and the customer CPEe 513 and IoTG 519 (which may beseparate or integrated, as in FIGS. 5a and 5b discussed above) transmitsand receives the IoT RF signals on the desired RF frequency channelcarried over the coaxial infrastructure of the MSO network in order toservice the IoT end device(s) 556 via their respective air interfaces.

In some implementations, the coaxial RF distribution network isconfigured to distribute the IoT channel using the desired RF channelfrequency (versus use of an intermediate frequency or IF which is thenupconverted/downconverted), and the CPEe 513/IoTG 519 will not modifythe IoT signal (i.e., a “pass through” configuration).

In other cases, the coaxial RF distribution network generates anintermediate frequency for distribution of the IoT channel, and theCPEe/IoTG upconverts/downconverts the IoT channel to the desired RFcarrier frequency (see discussion of FIGS. 9a and 9b , and 17-21 below).

The foregoing methodologies advantageously may be applied to 3GPP LTE,3GPP 5G NR, and non-3GPP (e.g. LoRa) IoT channels that are separate fromany other channels used for eMBB and/or system control information. The3GPP nomenclature for this configuration is “standalone” or “guardband”IoT channels.

Moreover, any number of modalities or PHYs may be used for datatransmission between the IoT end device(s) 556 and the CPE. For example,the exemplary “IoT” air interface spectra (i.e., BLE and IEEE Std.802.15.4) of FIGS. 16a and 16b and associated technologies may beemployed for data exchange between the CPEe 513/IoTG 519 and the IoTdevice(s) 556, the latter generally consuming comparatively low databandwidth as a general proposition.

FIG. 16a is a graphical representation of radio frequency bandsassociated with such IEEE Std. 802.15.4 and Bluetooth Low Energy (BLE)wireless interfaces, and their relationship. FIG. 16b shows the 5MHz-spaced channels of 3 MHz width used by 802.15.4 in the same band(s)as IEEE Std. 802.11. Accordingly, the present disclosure contemplatesuse of one or more of multiple unlicensed premises air interfaces fordata services to the IoT devices and the IoT devices 556 (and even theUE 507), consistent with their respective bandwidth requirements.

It will be appreciated that while the present disclosure is cast largelyin terms of delivery of 3GPP-based (4G/4.5G/5G) waveforms to therecipient CPEe 413 at the user's premises, and hence a requirement foradditional processing at the premises to convert these 3GPP waveformsinto waveforms compliant with other air interface standards (includingthose capable of consumption by IoT devices, such as IEEE Std. 802.15.4and BLE), such as via the gateway apparatus described in detail inco-owned U.S. patent application Ser. No. 16/______ filed concurrentlyherewith on Apr.______, 2019 and entitled “GATEWAY APPARATUS AND METHODSFOR WIRELESS IoT (INTERNET OF THINGS) SERVICES,” the present disclosurealso contemplates the creation of such IoT-compatible waveforms directlyat the transmitting nodes (e.g., nodes 401 and 411 of FIG. 4 herein)such as via an IEEE Std. 892.15.4 or BLE chipset operative to modulateand create the waveforms for the transmitted IoT bands prior totransmission over the cable medium. Moreover, the IoT devices may beconfigured to use the (upconverted) received 3GPP waveforms directly insome cases.

FIG. 17 depicts a frequency domain representation of an exemplary IoTchannel within the coaxial RF distribution network architecture of FIG.5. It will be noted that while RF channels having “shoulders” are shown(indicative of energy rolloff at the edges of the band(s)), thesefrequency/energy profiles are merely exemplary, and other types of bands(including those with other shoulder profiles) may be used consistentwith the present disclosure.

In the implementation of FIG. 17, the IoT channel bandwidth 1708 iscentered at the intended carrier frequency and coexists with upstream(US) 1702 and downstream (DS) 1704, 1706 spectrum used to service theCPEe on the network. In this approach, the IoT channel 1708 can besimply radiated and received by the CPEe 513/IoTG 519 without anyfurther processing or manipulation such as frequencyupconversion/downconversion, since it is already at the target carrierfrequency. The coaxial RF distribution network acts as an antennadistribution system for the IoT channel, and the CPEe as a pass-throughdevice, as previously described.

FIG. 18 depicts another frequency domain representation that may be usedconsistent with the present disclosure, wherein the IoT channel 1808occupies an otherwise unused portion of the RF distribution network(here, for example, below the US frequency band 1802), and is thenfrequency translated (upconverted or downconverted; in this exampleupconverted) to a band 1810 at the desired carrier frequency by the CPEe513/IoTG 519 at the customer premises. Note that since the upconversionhappens at the CPEe 513, there is no interference between theupconverted IoT band 1810 and the extant other bands on the HFC medium(e.g., the DS band which occupies a portion of the frequency spectrumthat includes the newly upconverted IoT band 1810).

It will be recognized that in both of the above frequency domaindiagrams (FIGS. 17 and 18), the IoT channel 1708, 1808 can beimplemented as a 3GPP IoT channel (i.e. eMTC, NB-IoT), or mayalternatively be configured according to a different IoT standard (e.g.,LoRa). Moreover, aggregations of heterogeneous channel types may be used(such as where one portion of the allocated IoT bandwidth 1708, 1808comprises a channel of the first type, and another portion a channel ofsecond, different type). Hence, although description of use with 3GPPtechnology has been given with respect to the exemplary embodiments,this aspect of the disclosure is in no way limited to use with only 3GPPtechnologies.

Referring now to FIG. 19a -21, yet another configuration of thefrequency spectrum useful with the architecture of FIG. 5 herein isdisclosed. In 3GPP LTE (and 5G NR) systems, a separate logical IoTchannel can be embedded within an overall LTE (and 5G NR) channel. Thisis known as the “in-band” deployment scenario. The IoT channel occupiesa number of physical resource blocks (PRBs) within the overall LTEchannel, but is logically separate with its own set of broadcast,control, and data sub-channels.

Accordingly, such an in-band IoT channel can be employed within thesystem architecture 500 that is compatible with 3GPP IoT standards (i.e.eMTC, NB-IoT), and this channel can be used for IoT transmissions tostandard IoT end devices such as those devices 556 in FIG. 5. Thecoaxial RF distribution network of FIG. 5 previously described serves asa distributed antenna system for the IoT channel and its “donor” or hostchannel, and the customer CPEe 513/IoTG 519 is used to transmit andreceive the IoT RF signals on the desired RF frequency channel at thepremises (i.e., to/from the IoT end device 556).

In some configurations, the coaxial RF distribution network willdistribute the aforementioned in-band IoT channel along with itsassociated bearer channel (e.g., LTE channel) using the desired RFchannel frequency, and the CPEe 513/IoTG 519 selectively filters the IoTsignal from the associated carrier for transmission to the IoT enddevice 556. As such, no frequency conversion is required. This approachhas the advantage of obviating the aforementionedupconversion/downconversion, but also requires the LTE or other host tocoincide in frequency with the IoT carrier.

In other configurations, the coaxial RF distribution network uses anintermediate frequency (IF) for distribution, and the CPEe 513upconverts/downconverts the selectively filtered IoT channel to thedesired RF carrier frequency upon receipt over the coaxialinfrastructure.

FIG. 19a depicts an exemplary in-band IoT channel 1908 within a host LTEchannel 1902. The IoT channel is logically separate from the rest of theLTE channel having its own broadcast, control, and data sub-channels, aspreviously noted. Moreover, more than one IoT channel 1908 a-c may behosted by a given LTE/5G channel (FIG. 19c ), and multiple LTE channels1902 a, 1902 b (whether contiguous in frequency or not) may hostseparate ones or portions of a single, IoT channel 1908 a, 1908 b, asshown in FIG. 19 b.

FIG. 20 depicts a frequency domain representation of an exemplary LTEchannel 2005 formed within the coaxial RF distribution networkarchitecture 500 of FIG. 5 herein. In this case, the IoT channel 2008exists at the intended carrier frequency, and hence can be selectivelyfiltered (e.g., by the RF receiver or front end of the CPEe 513/IoTG519), and then radiated to the IoT end user devices 556, and receivedfrom the devices 556 by the CPEe 513/IoTG 519, without any furtherprocessing or manipulation. As shown, the extant US band 2002, and DSbands 2004, 2006, co-exist with the LTE band 2005 on the RF coaxialbearer medium, with the IoT channel 2008 “nested” within the LTEchannel.

It will also be appreciated that designation of the IoT channelbandwidth with such architectures (and in fact others herein) may alsobe dynamic in nature. For instance, if no IoT channel bandwidth isrequired (such as when no IoT devices operable on such frequencies areoperational at the served premises), then the IoT bandwidth may becollapsed for at least a period of time and utilized as e.g., LTEbandwidth, or for other purposes. To the degreesignaling/control/broadcast channels are required to be maintained,these can be maintained on a time-shared basis.

FIG. 21 depicts another frequency domain representation according to thepresent disclosure, wherein the LTE channel 2105 occupies an otherwiseunused portion of the RF distribution network (here, at the lower end ofthe useable spectrum on the bearer medium), and the IoT portion 2108 isselectively filtered and then frequency translated to the desiredcarrier frequency 2110 by the CPEe 513/IoTG 519 at the customerpremises.

Methods

Referring now to FIGS. 22-23 c, methods of operating the networkinfrastructure of, e.g., FIG. 5 herein are shown and described.

FIG. 22 is a logical flow diagram illustrating one embodiment of ageneralized method 1800 of utilizing an existing network (e.g., HFC) forcontrol data communication. As shown, the method includes firstidentifying or generating control data (e.g., digital data used forconfiguring, reconfiguring, and operating network CPEe 513, IoTG 519, orother downstream network node) to be transmitted to the recipient deviceor node (e.g., a target CPEe 513 or IoTG 519 in communication therewith)per step 2202. This may be performed at the enhanced CU (CUe) previouslydescribed with respect to FIG. 6a-6f herein, or at another node orprocess (including one disposed further back toward the 5GC or EPC asapplicable).

Next, per step 2204, the transmission node 509 generates waveforms“containing” the generated control data. As described elsewhere herein,in one embodiment, this includes generation of OFDM waveforms andtime-frequency resources to carry the content data (e.g., PRBs) via oneor more designated control channels, including those embedded within orusing one or more LTE anchor channels. The overall waveform generationand transmission process may also include both: (i) application offrequency diversity in accordance with FIG. 8c herein, such as viaallocation of MIMO Ports 0 and 1 to respective wideband TDD carriers 732for the 5G NR or “in band” data and (ii) I-Q multiplexing onto one QPSKanalog synchronization channel within the aforementioned “minor portion”833 (FIG. 8c ) from the signal generator 818 of the transceiver node 509to the multiple inline amplifiers and CPEe 513 that may be sharing thecoaxial bus.

Note that for control data (such as for control of the CPEe 413), thefrequency diversity concept may still be applied, but depending onapplication may be unnecessary. As with 3GPP control data being sentusing so-called “transmit diversity” (i.e., wherein the same controldata is coded differently for transmission across two spatiallyseparated layers, so as to provide diversity of signal reception at theuser equipment (UE) and to improve the robustness of control signaling).the control data in some cases can be mapped to different frequencyresources on the coaxial cable so as to provide such benefits ifrequired.

Per step 2206, the waveforms are transmitted via the networkinfrastructure (e.g., coaxial cable and/or DWDM optical medium) to oneor more recipient nodes. It will be appreciated that such transmissionmay include relay or transmission via one or more intermediary nodes,including for instance one or more N-way taps (FIG. 5), optical nodes,repeaters, etc.).

Per step 2208, the transmitted waveforms are received at the recipientnode (e.g., CPEe 513 in one instance).

The waveforms are then processed to recover the transmitted control dataper step 2212, and applied to the target device (e.g., CPEe 513 and/orIoTG 519) per step 2214. For instance, in one variant, the CPEe may bereconfigured via the control data to change one or more of its RF frontend parameters such as MCS, frequency diversity scheme (FIG. 8c ), TDDslot assignment, or to enable/disable premises data distributionfunctions, or even indigenous higher-layer processes on the CPEe orconnected devices (e.g., to enable/disable a DCAS or other CA module,allow access to transmitted content, install software updates, etc.).The IoTG may similarly be reconfigured as to one or more of its airinterfaces, multiplexing schedule/scheme (if used), use of any IoTsniffer as previously described, etc.

FIG. 22a is a logical flow diagram illustrating one particularimplementation of control data processing and transmission methods 2220according to the generalized method of FIG. 22. Specifically, as shown,the method 1820 includes first designating the frequency mapping plan orallocation for the control channel per step 2224. In one variant, thismapping is in accordance with the scheme shown in FIG. 17; i.e., one ormore carriers are utilized within an LTE anchor band (such as one ofthose shown in FIG. 8c ). For instance, an eMTC-type of format may beused (1.08 MHz of bandwidth within the 18 MHz LTE channel) within theLTE anchor for control data, the designated (e.g., 1.08 MHz) banddisposed at a prescribed portion of the 18M MHz LTE anchor (includingany guard bands as needed).

It will also be appreciated that the frequency mapping plan for thecontrol channel may be varied on a temporal or other basis, includingbased on one or more TDD slots. For instance, the same mapping may beapplied on two or more contiguous slots, or per individual slot.Individual mappings may be used for one or more subsets of CPEe's 513 aswell, such as where the same subset of CPEe accesses the bearer mediumaccording to a prescribed TDD schedule, and all utilize the commonfrequency mapping.

Likewise, IoTG TDD-based (or other) multiplexing may be used for servingthe various IoTG air interfaces (and hence communicating IoT devices556), as well as for different IoTGs (whether at the same or differentpremises).

A serial-to-parallel conversion of the content data is then applied perstep 2226. Next, the parallelized data is mapped to its resources (step2228), and an IFFT or other such transformation operation performed toconvert the frequency-domain signals to the time domain (step 2230). Thetransformed (time domain) data is then re-serialized (step 2232) andconverted to the analog domain (step 2234) for transmission over e.g.,the RF interface such as a coaxial cable plant. In the exemplaryembodiment, an LTE anchor such as that shown in FIG. 8c is used,although it will be appreciated that other frequency bands (and in factmultiple different frequency bands in various portions of the spectrum)may be used for this purpose.

FIG. 23 is a logical flow diagram illustrating one embodiment of ageneralized method 2300 of utilizing an existing network (e.g., HFC) forIoT data communication. As shown, the method includes first identifyingIoT content (e.g., which may include IoT device control data, digitallyrendered media, or other data) to be transmitted to the recipient deviceor node (e.g., a requesting IoT end device 556, or a CPEe 513 or IoTG519 in communication therewith and acting as its proxy on the RFnetwork) per step 2302.

Next, per step 2304, the transmission node 509 generates waveforms“containing” the identified IoT data. As described below, in oneembodiment, this includes generation of OFDM waveforms andtime-frequency resources to carry the content data (e.g., PRBs). Aspreviously discussed, the waveform generation and transmission processmay also include both: (i) application of frequency diversity inaccordance with FIG. 8c herein, and (ii) I-Q multiplexing onto one QPSKanalog synchronization channel within the aforementioned “minor portion”833 (FIG. 8c ) from the signal generator 818 of the transceiver node 509to the multiple inline amplifiers and CPEe 513 that may be sharing thecoaxial bus depending on the particular application and need for controldata robustness as previously described.

Per step 2306, the waveforms are transmitted via the networkinfrastructure (e.g., coaxial cable and/or DWDM optical medium) to oneor more recipient nodes (which as noted above may be the CPEe 513 and/orIoTG 519 (whether separate or aggregated) acting as an endpoint/proxyfor the IoT end device 556, or the IoT device 556 itself acting as theendpoint if suitably equipped to receive and demodulate the transmittedOFDM signals in the transmission band.

It will also be appreciated that such transmission may include relay ortransmission via one or more intermediary nodes, including for instanceone or more N-way taps (FIG. 5), optical nodes, repeaters, etc.).

Per step 2308, the transmitted waveforms are received at the recipientnode (e.g., CPEe 513 or IoTG 519 in one instance, or IoT end device 556in another).

The waveforms are then processed (see discussion of FIG. 23a below) perstep 2312, and transmitted per step 2314 as needed via the local (e.g.,premises RAN or distribution medium such as the IoTG 519) for use by,e.g., consuming or requesting IoT end devices.

FIG. 23a is a logical flow diagram illustrating one particularimplementation of IoT content processing and transmission methods 2320according to the generalized method of FIG. 23. Specifically, as shown,the method 2320 includes first determining the frequency mapping plan orallocation for the transmission per step 2324. In one variant, thismapping is in accordance with the scheme 850 shown in FIG. 8c ; i.e., anumber of wideband carriers are utilized within an IF band (betweenf_(lower) and f_(upper)) along with 4G/4.5G carriers and asynchronization band.

As with the control data previously described, it will also beappreciated that the frequency mapping plan for the IoT data may bevaried on a temporal or other basis, including based on one or more TDDslots. For instance, the same mapping may be applied on two or morecontiguous slots, or per individual slot. Individual mappings may beused for one or more subsets of CPEe's 513/IoTG 519 (and/or IoT enddevices 556 acting as endpoints to terminate the IoT channel) as well,such as where the same subset of CPEe/IoT devices accesses the bearermedium according to a prescribed TDD schedule, and all utilize thecommon frequency mapping.

A serial-to-parallel conversion of the content data is then applied perstep 2326. Next, the parallelized data is mapped to its resources (step2328), and an IFFT or other such transformation operation performed toconvert the frequency-domain signals to the time domain (step 2330). Thetransformed (time domain) IoT data is then re-serialized (step 2332) andconverted to the analog domain (step 2334) for transmission over e.g.,the RF interface such as a coaxial cable plant within the designated IoTband(s). Consistent with the exemplary embodiment, various schemes canbe used (including for instance direct or pass-through transmission atthe desired terminal carrier frequency, or transmission at anotherfrequency followed by upconversion/downconversion to the desiredterminal carrier), although it will be appreciated that other frequencybands (and in fact multiple different frequency bands in variousportions of the spectrum) may be used for this purpose.

FIG. 22b is a logical flow diagram illustrating one particularimplementation of content reception and digital processing methods 2240by a CPEe according to the generalized method of FIG. 22. In this method2240, the CPEe 513 receives the transmitted waveforms (see step 2232 ofthe method 2220), and performs analog-domain upconversion to the targetfrequency (e.g., user band) per step 2242.

Per step 2244, the upconverted signals are synchronized via therecovered I/Q signals via the synchronization circuit of the CPEe, andthe upconverted signals are converted to the digital domain for use by,e.g., the chipset 916 of the CPEe 513 (see FIG. 9a ). Within thechipset, the digital domain signals are processed including inter aliaserial-to-parallel conversion, FFT transformation of the data back tothe frequency domain (step 2250), de-mapping of the physical resources(step 2252), parallel-to-serial conversion (step 2254), and ultimatelydistribution of the digital (baseband) data to e.g., the 10 GbE switch,Wi-Fi router, etc. (step 2256).

FIG. 23b is a logical flow diagram illustrating one particularimplementation of content reception and digital processing methods 2350by an exemplary receiver (e.g., CPEe 513 or IoTG 519) according to thegeneralized method of FIG. 23. In this exemplary method, the CPEe 513receives the transmitted waveforms (see step 2336 of the method 2320),and first performs selective filtering of the signal band per step 2351to isolate the IoT data band (e.g., within the host LTE anchor channel).In one variant, a bandpass filter is used to remove LTE anchor channelfrequencies that are not utilized as part of the embedded IoTchannel(s). For instance, the bandpass filtering may be applied in thesignal path after the receipt of the waveforms from the network suchthat the LTE anchor channel data (i.e., that not used for IoT datatransmission, but rather for maintenance and operation of the LTE userplane data/channel as required by the NSA configurations or 5G NR Option3. Alternatively, the IoT data may occupy TDD slots within thedesignated embedded IoT channel(s) such that filtering need only beapplied during those TDD slots, and the bandwidth used for otherpurposes (e.g., CPEe control data, LTE anchor channel functions, etc.)during the non-IoT allocated TDD slots. Various other schemes will berecognized by those of ordinary skill given the present disclosure.

In one particular implementation, an IoT channel which occupies aprescribed number of PRBs (e.g., either 1.08 MHz—6 PRBs, or 180 kHz—1PRB) can be embedded within an LTE channel (e.g. 18 MHz with 100 PRBstotal), and frequency domain bandpass filtering used to select thePRB(s) carrying the IoT channel.

Next, per step 2352, the receiver (e.g., CPEe) performs analog-domainupconversion to the target frequency (e.g., user band), although asnoted above, direct or “pass-through” transmission may be utilizedalternatively or in conjunction with upconversion (i.e., one band may bedirect, and another contemporaneously requireupconversion/downconversion).

Per step 2354, the upconverted signals are synchronized via therecovered I/Q signals via the synchronization circuit of the CPEe, andthe upconverted signals are converted to the digital domain for use by,e.g., the chipset 916 of the CPEe 513 (see FIG. 9a ). Within thechipset, the digital domain signals are processed including inter aliaserial-to-parallel conversion, FFT transformation of the data back tothe frequency domain (step 2360), de-mapping of the physical resources(step 2362), parallel-to-serial conversion (step 2364), and ultimatelydistribution of the digital (baseband) data to e.g., the 10 GbE switch,Wi-Fi router, BLE or IEEE Std. 802.15.4 air interface, etc. (step 2366).

FIG. 23c is a logical flow diagram illustrating one particularimplementation of content reception and transmission within a premisesby a CPEe/IoTG according to the generalized method of FIG. 23.Specifically, as shown in FIG. 23c , the method 2370 includesupconversion to the user band (step 2372) as in the method 2350described above, but rather than conversion to the digital domain as inthe method 2350, the upconverted analog domain signals are synchronized(step 2374) and provided to one or more repeater ports for transmissionof the upconverted waveforms via the antenna(e) of the repeater moduleper step 2376 (see FIG. 9a ). For example, in cases where the IoT deviceitself acts as the channel termination or endpoint, the receivedwaveforms (whether as a direct pass-through, or upconversion as in theexemplary embodiment of FIG. 23c ) can be transmitted in analog formover the local (short range) antennae of the CPEe 513 or CPEe/IoTG, ineffect forming the “last mile” of the distributed antenna systemafforded by the MSO HFC infrastructure.

It will be recognized that while certain aspects of the disclosure aredescribed in terms of a specific sequence of steps of a method, thesedescriptions are only illustrative of the broader methods of thedisclosure, and may be modified as required by the particularapplication. Certain steps may be rendered unnecessary or optional undercertain circumstances. Additionally, certain steps or functionality maybe added to the disclosed embodiments, or the order of performance oftwo or more steps permuted. All such variations are considered to beencompassed within the disclosure disclosed and claimed herein.

While the above detailed description has shown, described, and pointedout novel features of the disclosure as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art without departing from the disclosure. Thisdescription is in no way meant to be limiting, but rather should betaken as illustrative of the general principles of the disclosure. Thescope of the disclosure should be determined with reference to theclaims.

It will be further appreciated that while certain steps and aspects ofthe various methods and apparatus described herein may be performed by ahuman being, the disclosed aspects and individual methods and apparatusare generally computerized/computer-implemented. Computerized apparatusand methods are necessary to fully implement these aspects for anynumber of reasons including, without limitation, commercial viability,practicality, and even feasibility (i.e., certain steps/processes simplycannot be performed by a human being in any viable fashion).

1.-19. (canceled)
 20. Computerized apparatus configured to use of one ormore air interfaces within a premises for provision of IoT (Internet ofThings) data services, the computerized apparatus comprising: a datainterface, the data interface configured to communicate data with an RF(radio frequency) interface device of a network; processor apparatus indata communication with the data interface; a plurality of radioapparatus in data communication with the processor apparatus; andstorage apparatus in data communication with the processor apparatus andcomprising at least one computer program, the at least one computerprogram comprising a plurality of instructions which are configured to,when executed by the processor apparatus, cause the computerizedapparatus to: utilize the plurality of radio apparatus to scanrespective ones of radio frequency (RF) bands, each of the RF bandsassociated with a respective short-range communications protocol of aplurality of short-range communications protocols, the scans eachconfigured to detect energy associated with a first RF transmitter;based at least on the detection of energy within the respective RF band,cause synchronization with a signal emitted from the corresponding RFtransmitter using the respective short-range communications protocol;and based at least on said synchronization with the signal, causeutilization of a designated RF channel of the network.
 21. Thecomputerized apparatus of claim 20, wherein a first of the plurality ofshort-range communication protocols comprises an IEEE Std. 802.15.4protocol, and the synchronization with the signal comprises decode of abroadcast message transmitted from the first RF transmitter. 22.(canceled)
 23. The computerized apparatus of claim 20, wherein thedesignated RF channel comprises at least a portion of a 3GPP (3rdGeneration Partnership Project) LTE (Long Term Evolution) anchorchannel.
 24. The computerized apparatus of claim 23, wherein the 3GPPLTE (Long Term Evolution) anchor channel is part of a non-standalone(NSA) architecture utilized by the HFC cable network. 25.-30. (canceled)31. The computerized apparatus of claim 23, wherein the utilization ofthe designated RF channel comprises utilization of the at least portionof the 3GPP LTE anchor channel as a control channel for control of atleast one function of the computerized apparatus.
 32. The computerizedapparatus of claim 23, wherein the utilization of the designated RFchannel comprises utilization of the at least portion of the 3GPP LTEanchor channel as a user data channel for at least user data received bythe computerized apparatus from one or more wireless IoT devicescomprising the first RF transmitter.
 33. The computerized apparatus ofclaim 20, wherein the designated RF channel comprises at least a portionof a 3GPP (3rd Generation Partnership Project) 5G NR (New Radio) NB-IoTchannel.
 34. The computerized apparatus of claim 20, wherein the networkcomprises a managed a hybrid fiber coax (HFC) cable network, and the RFinterface device comprises a consumer premises equipment (CPE), the CPEconfigured to communicate radio frequency waveforms with at least oneRF-enabled node of the network.
 35. The computerized apparatus of claim34, wherein: the radio frequency waveforms comprise waveforms compliantwith at least one of a 3GPP (3rd Generation Partnership Project) LTE(Long Term Evolution) or 5G NR (Fifth Generation New Radio) standard;and the at least one RF-enabled node of the network comprises at leastone of a 3GPP 5G NR compliant CU (Control Unit) or DU (distributedunit).
 36. A computerized method of utilizing a hybrid fiber coaxial(HFC) radio frequency (RF) network for distribution of radio frequencysignals encoding IoT (Internet of Things) data, the computerized methodcomprising: utilizing a first portion of an RF operating spectrum of thehybrid fiber coaxial (HFC) radio frequency network to providecommunications compliant with a first wireless technology; and utilizinga second portion of the RF operating spectrum to provide the IoT datavia communications compliant with a second wireless technology; whereinthe utilizing the second portion of the RF operating spectrum to providethe IoT data via communications compliant with the second wirelesstechnology comprises utilizing a computerized gateway apparatus having aplurality of heterogeneous air interfaces for distribution of respectiveportions of the IoT data to respective IoT devices within a premisesserved by the computerized gateway.
 37. The computerized method of claim36, wherein the utilizing of the first portion of the RF operatingspectrum of the HFC RF network to provide the communications compliantwith the first wireless technology comprises utilizing the first portionof the RF operating spectrum of the HFC RF network to providecommunications compliant a 3GPP 5G NR (New Radio) compliant technology,and the utilizing of the second portion of the RF operating spectrum toprovide the IoT data via the communications compliant with the secondwireless technology comprises utilizing the second portion of the RFoperating spectrum to provide the IoT data via communications compliantwith a 3GPP LTE (Long Term Evolution) compliant technology that is not5G NR compliant.
 38. The computerized method of claim 36, wherein: theutilizing the first portion of the RF operating spectrum of the HFCradio frequency network to provide the communications compliant with thefirst wireless technology comprises using the first portion according toa TDD (time division duplex) scheme; and the utilizing the secondportion of the RF operating spectrum to provide the IoT data via thecommunications compliant with the second wireless technology comprisesusing the second portion according to an FDD (frequency division duplex)scheme.
 39. The computerized method of claim 36, wherein the utilizingthe first portion of the RF operating spectrum of the HFC radiofrequency network to provide communications compliant with the firstwireless technology comprises applying a frequency shift to a first datastream associated with a first MIMO (multiple input, multiple output)port relative to a second port, the first and second ports associatedwith the first wireless technology.
 40. The computerized method of claim36, wherein the utilizing the second portion of the RF operatingspectrum to provide the IoT data via the communications compliant withthe second wireless technology further comprises upconverting waveformsreceived by an RF premises device in data communication with thecomputerized gateway apparatus in frequency prior to distribution to thecomputerized gateway apparatus.
 41. A computer-readable apparatuscomprising a non-transitory storage medium, the non-transitory storagemedium comprising a plurality of instructions configured to, whenexecuted by a processor apparatus of a computerized receiver apparatus,cause the computerized receiver apparatus to: receive one or more radiofrequency (RF) waveforms transmitted over a wireline data network, theone or more RF waveforms carrying control data, the control datacomprising digital data used for at least one of configuring orreconfiguring the computerized receiver apparatus; process the one ormore RF waveforms to obtain the control data; and change one or more RFparameters of the computerized receiver apparatus based at least on thecontrol data.
 42. The computer-readable apparatus of claim 41, whereinthe change of the one or more RF parameters of the computerized receiverapparatus based at least on the control data comprises a change to 3GPP(Third Generation Partnership Project) eMTC-type of format used within a3GPP LTE (Long Term Evolution) anchor channel.
 43. The computer-readableapparatus of claim 41, wherein the plurality of instructions are furtherconfigured to, when executed by the processor apparatus of acomputerized receiver apparatus, cause the computerized receiverapparatus to: perform a frequency up-conversion from a transmissionfrequency used for the transmission of the RF waveforms over thewireline data network to a user frequency band; perform ananalog-to-digital conversion of the transmitted and up-converted RFwaveforms to produce digital data; perform a serial-to-parallelconversion of the up-converted digital data.
 44. The computer-readableapparatus of claim 41, wherein the processing of the one or more RFwaveforms comprises: selective filtering of a signal band associatedwith the one or more RF waveforms to isolate an IoT (Internet of Things)data band within a 3GPP LTE (Long Term Evolution) anchor channel; anduse of a bandpass filter to remove one or more LTE anchor channelfrequencies that are not utilized as part of an IoT channel embeddedwithin the LTE anchor channel.
 45. The computer-readable apparatus ofclaim 41, wherein the processing of the one or more RF waveformscomprises: an analog-domain up-conversion of the one or more RFwaveforms to a user band frequency; and synchronization of the one ormore upconverted RF waveforms via I/Q (In-phase/Quadrature) signalsrecovered via a synchronization circuit of the computerized receiverapparatus.
 46. The computer-readable apparatus of claim 41, wherein: thecomputerized receiver apparatus comprises a receiver apparatusconfigured for use at a premises of a subscriber of a managed HFC(hybrid fiber coax) cable network, the wireline data network comprisingthe managed HFC cable network; and the RF waveforms are generated andtransmitted by 3GPP (3rd Generation Partnership Project) 5G NR compliantDU (distributed unit) disposed within the managed HFC cable network.